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ABSTRACT : Eight  Artificial  Intelligence  programming  languages 

(SAIL,  LISP,  MICROPLANNER,  CONNIVER,  MLISP,  POP-2,  AL  and  QLISP) 
are  presented  and  surveyed,  with  examples  of  their  use  in  an 
automated  shop  environment.  Control  structures  are  compared,  and 
distinctive  features  of  each  language  are  highlighted.  A simple 
programming  task  is  used  to  illustrate  programs  in  SAIL,  LISP, 
MICROPLANNER  and  CONNIVER.  The  report  assumes  reader  knowledge 
of  programming  concepts,  but  not  necessarily  of  the  languages 
surveyed . 


This  report  was  funded  by  the  National  Bureau  of  Standards, 
and  by  the  Office  of  Naval  Research. 
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This  report  describes  sone  recently  developed  Artificial 
Intelligence  programming  languages  in  the  context  of  a computer-aided 
manufacturing  environment*  The  languages  surveyed  are  SAIL,  LISP, 
MICROPLANNER,  CONNIVER,  MLISP,  POP-2,  AL,  and  ALISP.  These  languages, 
are  distinct  from  languages  previously  used  in  computer-aided 
manufacturing  environments  LLeslie723  in  that  they  provide  capabilities 
for  the  development,  of  high-level  symbolic  planning  and  supervisory 
control  in  addition  to  the  simple  numerical  control  of  machine  tools. 
The  paper  includes  (1)  surveys  and  comparisons  of  the  distinctive 
features  of  these  languages  as  they  might  be  used  in  a 
computer-automateo  manufacturing  environment,  (2)  a sample  automatcc 
manufacturing  task,  and  how  it  might  be  expressed  as  a program  in  each 
language,  (3)  discussions  of  the  s tanca rd iya t ion  status  of  each 
language,  and  (A)  conclusions  with  emphasis  on  the  types  of  features 
which  are  most  desirable  ana  applicable  to  the  automated-shop 
environment • 
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2*  SAIL 


2.1.  ln$£0^yciifin 

SAIL  has  its  origins  in  a merger  of  LEAP  CFelaman69j.  an 
associative  language*  and  a version  of  ALGOL  60  LNaur60j.  Therefore, 
unlike  most  of  tne  other  artificial  intelligence  languages,  it  is  not 
LISP-basea.  Insteaa.  it  is  a general  purpose  compiled  language  with  an 
extensive  run-time  library  of  functions.  As  befits  its  ALGOL  origins. 
SAIL  has  block  structure  and  explicitly  typed.  statically  scopec 
variables.  The  data  types  available  include  INTEGER.  REAL.  STRINGS  of 
arbitrary  length,  structure,  pointer,  LIST,  SET,  ITEM,  and  aggregates 
of  the  previous  ii.e.,  ARRAYs). 

Some  of  the  more  important  features  of  SAIL  are  discusses 
separately  below.  These  include  the  associative  data  base  facility, 
the  capability  for  usage  of  SAIL  as  a host  language  in  a CODASYL 
CC0DASYL71D  data  base  management  system,  the  control  structures,  an: 
the  system  building  facilities.  Finally,  a summary  is  presented  of 
current  s tanaa rdi zati on  efforts. 


2.2.  Associative  Data  base 

SAIL  contains  an  associative  data  base  facility  known  as  LEaP 
which  is  used  for  symbolic  computations  This  enables  the  storage  and 
retrieval  of  information  oased  on  partial  specification  of  the  data. 
Associative  data  is  stored  in  the  form  of  associations  which  are 
ordered  three-tuples  of  ITEMS,  denoted  as  TRIPLES.  Examples  o * TRIPLES 
a re  : 

FASTEN  X 0 R NAIL  EQV  HAMMER; 

FASTEN  XOR  SCREW  EQV  SCREWDRIVER; 

FASTEN  XOR  bOLT  EQV  PLIER; 

Associations  may  be  c on cept ua l i zee  as  representing  a relation  of  the 
form 

Attrioute  XOR  Object  EQV  Value 
or  Attrioute  (Object)  = Value 


Most  programming  languages  <e.g.»  LISP)  provide  the  following 
associative-like  mechanism: 

Given:  A t t r i uu t e , Ob j e c t 

Find:  Value 


However.  SAIL  enaoles  the  programmer  to  specify  any  of  the  components 
of  the  association,  ana  then  have  the  LEAP  interpreter  search  the 
associative  store  for  all  triples  which  have  the  same  items  in  the 
specified  positions.  For  example,  the  following  may  be  uses  tc 
retrieve  all  items  that  can  fasten  a nail: 

FASTEN  XOR  NAIL 

f 

An  ITEM  is  a constant  and  is  similar  to  a LISP  atom.  Items  have 
names  ana  may  also  be  typed  so  that  data  can  be  associated  with  them. 
An  item  may  be  declared,  or  created  during  execution  from  a storage 
pool  of  items  by  use  of  the  function  NEw.  For  example: 


REAL  ITEM  VISE; 


declares  VISE  to  ue  an  Item  which  may  have  a datum  of  type  real 
associated  with  it*  The  datum  associated  with  an  item  is  obtained  ty 
use  of  the  function  DATUM.  Thus,  DATUM(VISE)  might  be  interpreted  «s 
the  capacity  of  the  vise* 

In  order  to  deal  with  items,  the  user  has  the  capability  of 
storing  them  in  variables  (ITEMVARs).  SETs,  LlSTs,  and  associations. 
The  distinction  between  SETs  and  LISTs  is  that  an  explicit  order  is 
associatec  with  the  latter,  whereas  there  is  no  explicit  order 
associateo  with  the  former.  In  addition,  an  item  may  occur  more  than 
once  in  a List. 

Associations  are  ordered  three-tuples  of  items  and  may  themselvts 
be  considered  as  items  and  therefore  participate  in  other  associations. 
Triples  are  added  to  the  associative  store  by  use  of  a v *k  E statement 
and  eraseo  from  the  associative  store  by  use  of  an  ERASE  statement. 
For  example,  the  following  code  could  be  used  to  detach  assembly  1 from 
assembly  2 and  attach  it  to  assemoly  3: 

ERASE  ATTACHED  XOR  ASSEMBlYI  EQV  A S SEMBL Y 2 ; 

MAKE  ATTACHED  XOR  ASSEMBLYI  EQV  A S SEMfcL  Y 3 ; 


The  motivation  for  using  an  associative  store  is  a flexible  search 
and  retrieval  mechanism.  Binding  Eooleans  and  Foreach  statements  are 
two  methods  of  accomplishing  these  goals. 

The  binding  boolean  expression  searches  the  associative  store  fcr 
a specified  triple  and  returns  TRUE  if  the  triple  is  found  and  FALDL 
otherwise.  The  aim  of  the  search  is  to  fino  an  association  which  meets 
the  constraints  imposed  by  the  specified  triple.  If  some  of  the 
components  of  the  triple  are  unknown  (such  components  are  preceded  ty 
the  special  item  BIND),  then  a successful  search  will  result  in  the 
binding  of  the  designated  component.  For  example: 

IF  FASTEN  XOR  BIND  OBJECT  EQV  PLIER  THEN  PUT  OBJECT  IN  PLIEk!SET; 


In  this  case  the  store  is  searched  for  an  object  that  can  be  fastened 
by  a PLIER  and  if  such  an  object  is  found,  it  is  placed  in  the  set 
PLIER! SET • Note  the  use  of  the  item  variable  OBJECT  in  the 
association.  A successful  search  will  result  in  this  variable  being 
bound • 

The  FOREACH  statement  is  the  heart  of  LEAP.  It  is  similar  to  the 
FOR  statement  of  AuGOL  in  that  the  body  of  the  statement  is  executed 
once  for  each  binding  of  the  control  variable.  For  example: 

FOREACH  X | PART  XOR  B747  EQV  X AND  DATUM  ( X)  < 3 
DO  PUT  X IN  B747S0RDER  !SET; 


In  this  case,  assuming  that  the  datum  associated  with  each  part  denotes 
quantity  at  hand,  the  associative  store  is  searched  for  all  parts  of  a 
B?47  ot  which  there  are  less  than  three  on  hand.  These  parts  are 
placed  in  the  set  374 7 ! ORDE R ! SET  • 


2.3.  £21*  M2Q2S£ E5.D1  ££ElUiX 

Unlike  other  artificial  intelligence  languages,  SAIL  has  the 
capability  of  being  used  with  an  existing  data  base  management  system 
(DBMS-10  lDECD)  to  handle  large  data  bases  stored  on  external  storage. 
An  interface  exists  CSamet76J  which  allows  SAIL  to  be  used  as  the  oata 
manipulation  language  in  a CODASYL  based  data  base  management  system. 
SAIL  is  relatively  unique  in  this  respect  in  that  COBOL  CCOBOL743  has 


almost  i«en  exclusively  used  as  the  data  manipulation  lansuaae  (DFL)  of 
such  systems*  This  situation  is  not  surprising  since  examination  of 
the  aata  description  facility  of  the  CCDASYL  report  reveals  a very 
strons  similarity  to  the  data  division  of  COBOL.  Nevertheless,  there 
have  oeen  some  attempts  to  use  FORTRAN  (CStacey743»  CRAPIDATA3). 

Ideally;  a data  manipulation  language  should  include  the  following 
features.  First,  a full  procedure  capacility  which  allows  pa ra meter 
passing,  aynamic  storage  allocation,  ano  recursion.  Second*  processing 
of  Boolean  requests  should  not  be  difficult.  In  a CCBOL-oaseo  system 
this  task  is  rather  cumbersome  as  pointed  out  by  CParsons7A3.  in  order 
to  avoid  currency  proDlems  raised  by  partial  satisfaction  of  Buole«n 
requests  (the  backtracking  problem  CTaylor763),  the  user  must  build 
collections  of  pointers  to  related  records.  Third,  there  should  be  a 
capability  for  builoing  an  in-core  data  base  so  that  operations  such  .s 
set  UNION  and  set  INTERSECTION  can  be  performec  without  the  overhead  of 
accessing  extended  storage  more  than  once  for  any  record. 

SAIL  has  a mechanism,  LEAP,  for  building  associative  data  oases. 
Currently,  this  only  works  for  internal  memory  due  to  implementation 
decisions.  SAIL  also  has  a record  structure  capability  which  enables 
the  user  to  build  an  in-core  uata  base.  In  a COEOL-based  data  base 
management  system,  whenever  the  user  obtains  an  instance  of  a recoro 
type  from  the  data  Base  (i.e.,  he  locates  it  via  a FIND  ano  fetches  it 
via  a GET),  he  has  no  convenient  way  of  keeping  it  in  temporary  memory 
while  obtaining  another  instance  of  this  record  type.  Of  course,  r.e 
can  allocate  temporary  storage  for  the  various  fields;  however,  this 
becomes  rather  unwieldy,  especially  when  he  wishes  to  keep  track  cf 
more  than  two  instances  of  a record  type.  Alternatively,  instances  cf 
certain  record  types  can  be  refetched  from  the  data  base.  In  fact, 
this  is  the  strategy  that  is  generally  followed.  However,  the  cost  is 
orohibitive. 

oriefly,  the  SAIL  interface  provides  a SAIL  recoro  structure 
declaration  for  each  record  type  that  has  been  defined  in  the  data  base 
management  system.  Primitives  exist  for  the  creation  ano  modification 
of  such  records.  The  dynamic  storage  allocation  capability  of  SAIL 
enables  the  creation  of  several  instances  of  each  recoro  type  each  of 
which  is  identified  b>  an  entity  known  as  a record  pointer. 

As  an  example  of  the  use  of  .<<11.  as  a host  language  in  a data  base 
management  system,  consider  the  f * Hawing  program  fragment.  The  task 
is  to  traverse  a set  named  SI  ;P'  JF.R  owned  by  a WAREHOUSE  record  and 
extract  an  integer  aata  item  kr  . a r PART  NUM  from  each  PART  record 
which  is  a member  of  the  set.  f i.  <?  ezact  instance  of  the  set  occurrence 
is  identified  by  the  owner  record,  WAREHOUSE,  having  the  value 
ELECTRICAL  for  the  data  item  INDUSTRY.  Since  SAIL  has  a data 
structuring  facility  (known  as  a RECORD!CLASS  and  similar  to  a FL/1 
Caeech703  structure)  we  define  a data  structure  known  as  L1STX  ano  a 
function  to  add  items  to  the  front  of  a L1STX  structure.  The  data 
structure  LISTX  has  two  fields  - ELEMENT  which  is  of  type  INTEGER  ana 
NEXT  which  is  of  type  RECORDiPOINTER  (and  points  to  another  instance  of 
the  LISTx  data  structure).  The  function  AD DT CL  1 ST  has  two  arguments  - 
a pointer  to  the  head  of  an  instance  of  LISTX  and  the  integer  to  pe 
added  to  this  instance. 

R EC  ORD  ! CL  ASS  L I S TX ( I N T c G E R ELEMENT; 

SE  COR  > '.POINTER  (LISTX)  NEXT); 

procedure  add  to  l is  t ( , f.  t *■  * l -xo  t record!pointer(listx)  head; 

tMYL'-.k  VAL); 

BEGIN 

RECORDlPOINTER  O-ISP'.  TEMP; 

TEMP  ;=  NEW  !ELEKf.WT  *LISTX); 

LI STX  :ELEMENTCTEMP3  :=  VAL; 

LI STX  :NLXTCTEMP3  :=  HEAD; 

HEAD  :=  TEMP; 

END; 


The  COBOL / DML  ana  SAIL  encodings  are  given  below.  The  criticol 


mm 


difference  is  the  step  "Add  PARTNUM  in  PART  to  result  list."  It  is  not 
immediately  obvious  how  the  concept  of  a list  would  be  implemented  in 
COBOL. 


COBOL  Program: 

MOVE  "ELECTRICAL'  TO  INDUSTRY  IN  WAREHOUSE. 
FIND  WAREHOUSE  RECORD. 

IF  SUPPLIER  SET  EMPTY  GO  TO  NONE ! SUPPL IE D . 
NLXT : FIND  NEXT  PART  RECORD  OF  SUPPLIER  SET. 

IF  ERROR-STATUS  = 030?  GO  TO  ALLiFOUND. 

6ET  PART. 

Aud  PARTNUM  in  PART  to  result  list. 

GO  TO  NEXT. 

AlL ! FOUND  : 


SAIL  Program: 

INDUSTRY  : = "ELECTRICAL"; 
FIND?CALC(WARcHOUSE); 

IF  EMPTYJSETCSUPPLIER)  GO  TO  NONE ! SUPPLIED; 
WHILE  TRUE  DO  BEGIN 

FIND !NEXT(PART, SUPPLIER); 

IF  ERROR  ! S TATUS  = 0307  THEN  DONE; 

GET (PART) ; 

ADDTOLIST (HEAD, PARTNUM); 

END; 


2.4.  C2nirfii  §Sryciyr£5 

In  aodition  to  the  ususal  control  structures  associated  with 
ALGOL-like  languages  (e.a.,  FOR  loops,  WHILE  loops,  case  statements, 
recursive  procedures,  etc.;,  SAIL  has  capabilities  to  enable  parallel 
processing,  backtracking,  and  coroutines.  In  SAIL,  a process  is  » 
procedure  that  may  oe  run  i ndepenoent  ly  of  the  main  procedure.  Thus 
several  processes  may  ue  run  concurrently.  Note  that  the  main 
procedure  is  also  a process. 

A process  is  created  with  a SPROUT  statement  as  follows: 

SPROUT (<i tem>,<procedure  call>,<options>) 


where  <ittm>  names  the  process  for  future  reference,  <procedure  call> 
indicates  what  the  process  is  to  do,  and  <options>  is  used  to  specify 
attributes  of  the  SPROUTed  and  current  process.  Unless  otherwise 
stipulated  (in  <options>),  a SPROUTed  process  begins  to  run  as  soon  as 
it  is  SPROUTed  and  in  parallel  with  the  SPROUTing  process. 

Similarly,  there  exist  primitives  which  result  in  the  suspension 
of  a process,  the  resumption  of  a process,  and  in  the  blocking  of  a 
process  until  a number  of  other  processes  have  terminated.  These  tasks 
are  accomplished  by  the  SUSPEND,  RESUME,  and  JOIN  primitives 
respect  ively. 

SUSPEND  and  RESUME  have  as  their  arguments  single  items  while  JOIN 
has  a set  of  items  as  its  argument.  These  items  are  the  names  that 
have  been  set  up  for  the  process  by  an  appropriate  SPROUT  command. 

For  example,  a procedure  to  tighten  a bolt  may  be  defined  as 
f ol  lows : 


ITEM  PI  ,P2; 


SPROUT (Pi ,GRASP (HAND1 , SCREWDRIVER) ); 
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SPROUT  CP2 , GRASP (HAND 2, DOLT)); 

J 01 N <{  PI  , P2>)  ; 

TURN(HAND1, CLOCKWISE); 


Since  SAIL  runs  on  a single  processor  computer  system,  true 
multiprocessing  is  not  possible.  Instead,  the  SAIL  runtime  system 

contains  a scheduler  which  decides  which  process  is  to  run  and  for  he. 
long.  The  programmer  makes  use  of  the  <options>  field  of  the  SPRCoT 
statement  to  specif/  information  which  the  scheduler  uses  to  determine 
the  next  process  to  be  run.  Such  information  includes  time  quantum 
sizes,  priority,  whether  or  not  to  immediately  run  the  SPKOUTeo 
process,  etc. 

A process  may  result  in  the  binding  of  I^MVARs  by  use  of  c. 
MATCHING  PROCEDURE  which  is  basically  a boolean  procedure.  When  one  of 
the  parameters  is  an  unbound  FOREACh  itemvar,  then  upon  success  the 
parameter  will  be  bound  . The  matching  procedure  is  actually  SPAOUTtc 
as  a coroutine  process  and  SUCCEED  ana  FAIL  are  variants  of  RESUPE 
which  return  values  of  TRUE  or  FALSE  respectively.  In  addition,  FAIL 
causes  the  process  to  terminate  whereas  when  the  matching  procedure  is 
callea  by  the  surrounding  FOREACH  via  backup,  then  the  procedure  is 
resumed  where  it  left  oft  on  the  last  SUCCEED. 

For  example,  consider  a box  containing  a number  of  different 
fasteners  (nails,  regular  screws,  bolts,  nuts,  tacks,  etc.).  The  goal 
is  to  obtain  Phillips  screws.  This  can  be  achieved  by  the  following 
MATCHINo  PROCEDURE  which  returns  a different  Phillips  screw  each  time 
it  is  invoked. 

MATCHING  PROCEDURE  GET ! F AS  TENER  (?  ITEMVAR  F AS T E ME R , F ! T YPE ) ; 

BEGIN 

FOREACH  FASTENER  | FASTENER  IN  BOX  AND 

TYPE  XOR  FASTENER  EQV  F'TYPE 

DO  SUCCEED; 

FA  IL; 


Note  that  FASTENER  is  a FOREACH  ITEMVAR  which  upon  success  will  oe 
bound . 

backtracking  is  supported  by  variables  of  type  CONTEXT.  However, 
the  programmer  must  specify  the  points  to  which  backup  is  to  occur  (for 
example,  recall  SUCCEED).  State  saving  and  restoring  is  achievea  ty 
use  of  CONTEXT  variables  which  act  as  pointers  to  storage  areas  of 
undefined  capacity  in  which  are  stored  the  entities  to  be  saved  and 
restored.  Actual  state  saving  ana  restoring  is  accomplish eo  by  use  uf 
the  primitives  REMEMBER  and  RESTORE. 

Processes  ma * communicate  with  each  other  by  use  of  the  sail  event 
mechanism.  This  is  a message  processing  system  which  enables  the 
programmer  to  classify  the  messages  and  to  wait  for  certain  events  to 
occur.  Events  occur  via  the  CAUSE  const ruct  which  has  as  its  arguments 
the  event  type,  the  actual  notice,  and  instructions  with  respect  to  the 
disposition  of  the  event.  Similarly,  there  is  a construct  known  as 
INTERROGATE  which  specifies  a set  or  event  types  and  instructions  with 
respect  to  the  disposition  of  the  event  notice  associatea  with  the 
designatec  event  types.  A variant  of  this  facility  has  been  usee 
extensively  in  the  implementation  of  the  Stanford  Hand  Eye  Project 
CFeldman7lJ. 
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sail  includes  many  features  which  are  designed  to  aid  in  system 
building.  Assembly  language  statements  may  oe  interspersed  with 
regular  SAIL  statements  by  use  of  the  STARTiCODE  and  CUICK’CODE 
constructs.  A number  of  different  files  which  are  to  be  used  with  the 
program  can  be  specified  via  use  of  REQUIRE  statements. 

The  statements: 

REQUIRE  "TOOLS"  LOAD {MODULE; 

REQUIRE  "CAHL1BC1,33"  LIBRARY; 


will  cause  SAIL  to  inform  the  loader  that  the  file  TOOLS.REL  must  ce 
loadeu.  In  addition.  the  file  CAMLIE  on  disk  area  C 1 * 3 3 serves  as  a 
library  and  is  searched  for  needed  routines. 

The  statement: 

REQUIRE  "HEADER .SAI"  SOURC  E ! F IL  E; 


will  cause  the  compiler  to  save  the  state  of  the  current  input  file* 
and  scan  HEADER. SAI  for  program  text.  When  HEADER. SAI  is  exhaust^c, 
scanning  of  the  original  file  resumes  at  a point  immediately  following 
the  REQUIRE  statement.  This  feature  is  particularly  useful  when 
dealing  with  libraries  since  in  this  case  the  REQUIREd  file  can  contain 
EXTERNAL  oeclarations  thereby  freeing  the  application  programmer  from 
such  work  and  possiole  errors* 

A rather  extensive  conditional  compilation  capability  is 
associateu  with  SAIL.  This  enables  the  development  of  large  programs 
which  can  be  paramete ri zed  to  suit  a particular  application  without 
compiling  unnecessary  code  and  thereby  wasting  memory  for  program 
segments  which  are  never  used.  This  capability  is  used  to  enahance  a 
macro  facility  to  include  compile-time  type  determination;  for  loops, 
while  statements,  and  case  statements  at  comp i l e - t i me ; generation  of 
unique  symbols,  ana  recursive  macros.  For  example: 

DtFINE  GRASP(SIZE)  = tlFCR  SIZE  > 1 THENC  VISE 

ELSEC  PLIERS 
ENDC  3; 


results  in  the  definition  of  a macro  named  6RASP  having  one  form«.l 
parameter,  SIZE.  The  result  is  the  name  of  a tool  that  is  appropriate 
for  the  size  of  the  item  that  is  to  be  grasped  - i.e.,  a vise  in  case 
size  is  greater  than  1 (assuming  size  is  measured  in  centimeters,  etc.) 
and  pliers  otherwise.  For  example: 

TC0L1  :=  uRAS  P< 10. 0) ; 

TOOL2  :=  GRASP(0.5); 


will  result  in  the  following  statements: 

TC0L1  :-  VISE; 

T00L2  :=  PLIERS; 


Note  that  the  choice  is  made  at  compile-time  and  thus  the  programmer 
need  not  be  concerned  with  the  available  grasping  mechanisms  Thus  the 
program  compilation  step  can  be  used  to  aid  in  the  writing  of  the 
program.  The  example  illustrates  the  importance  of  such  a feature  when 
certain  tasks  can  be  achieved  by  similar,  yet  not  identical,  means. 

SAIL  also  provides  an  excellent  interface  with  the  operating 
system.  This  enables  its  use  for  real-time  applications  such  as 
control  of  external  devices.  In  fact,  interrupts  can  be  handled  ano 
the  user  has  at  his  disposal  all  of  the  I/O  capabilities  that  an 
assembly  language  programmer  has.  This  enables  the  development  of 
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programs  ranging  from  scanners  to  mechanical  arm  controllers.  In 
addition  to  compatibility  with  assembly  language  debuggers,  SAIL  has  a 
high-level  breakpoint  package  known  as  MIL  CReiser75J. 


2.6.  S ta nda rd i^a iign 

Currently,  SaIL  nas  only  been  implemented  on  the  PDP-10.  It  runs 
under  both  the  TENEX  CbBN  E X t C 3 ana  T0PS-1G  CT0PS103  operating  systems. 
There  is  an  effort  underway  at  SUMEX  to  develop  a language  similar  to 
SAIL  known  as  MAINSAIL  Cwilcox763.  The  goal  of  that  project  is  to 
capture  the  features  that  make  SAIL  an  attractive  language  (in 
particular  the  ease  of  interaction  with  the  operating  system)  ana  to 
develop  a language  that  is  capable  of  being  run  on  a large  number  of 
machines.  The  orientation  of  the  project  is  towards  mini-computers. 
The  language  is  considerably  different  than  SAIl  and  existing  SAIL 
programs  will  have  to  be  moaified  in  order  to  be  capable  of  compilin-,. 
An  extensive  run  time  library  is  being  providea  as  is  a record 
structuring  facility.  It  is  still  uncertain  wnether  the  associative 
data  base  capability  of  SAIL  (i.e.,  LEAP)  will  be  incorporated  in 
MAINSAIL. 


3*  its.  use  Family  of  Lioaums 


I 

I 

I 


3.1.  L I£  P 

LISP  (CMcCarthybO],  CLevin653,  CWeissman6?3,  CSlktossy763),  i list 
processing  language  developed  by  John  McCarthy  at  MIT  in  the  late  5C  s> » 
is  an  implementation  of  parts  of  Alonzo  Church's  work  CChurchAID  in  the 
lambda  calculus.  McCarthy  s intention  was  to  recast  the  elegarr"  of 
recursive  function  theory  as  a theory  of  computation.  Thus*  thf  ri rst 
implementations  of  LISP  relied  exclusively  upon  recursion  as  the 
computational  paraoi*m  (i.e.*  no  iteration)*  which*  although  elegant, 
resulted  in  a first  version  of  LISP  which  was  not  competitive  with 
FORTRAN  as  a practical  programming  tool.  However,  LISP's  character  has 
changed  considerably*  so  that  today  LISP  is  an  extremely  powerful  ar.o 
general  purpose  programming  language  which  nevertheless  retains  its 
origina l elegance . 

The  most  interesting  features  of  LISP  .re: 

11)  The  language  is  practically  devoid  of  syntax;  all 
constructions  in  LISP  fall  into  two  categories;  atoms  and 
compositions  of  atoms. 

(2)  Program  ano  data  are  interchangeable*  since  they  are 
represented  in  the  same  format.  Therefore,  in  LISP  it  is 
possiole  for  one  function  to  construct  another  function  as 
data*  then  execute  it  by  indicating  to  the  LISP  system  to 
regard  it  as  code;  alternatively,  an  existing  function's 
code  may  be  examined,  modified  or  augmented  by  another 
function  at  run-time.  In  fact*  a function  is  capable  of 
self-modification  if  appropriate  care  is  exercized. 

(3)  Memory  allocation  and  management  are.  automatic  and 
transparent  to  the  user*  except  where  the  user  explicitly 
desires  to  influence  them,  With  the  exception  of  ar-ays, 
there  are  no  space  declarations  to  be  made*  freeinc  the 
programmer  from  the  details  of  space  allocation,  and 

§enerally  allowing  for  the  unlimited  growth  of  any  given 
ata  structure.  (For  the  most  part,  LISP  data  structures 
hove  no  size  or  complexity  constraints.)  Used  memory  which 
is  no  longer  involved  in  the  computation  is  recycled 
automatically  by  a garbage  collector  either  on  demand  from 
the  user  at  specified  points  or  automatically. 

(A)  LISP  is  an  interpreted  language.  The  system  proper  is  a 
function  of  one  argument,  (EvAL  X),  such  that  calling  EVAL 
with  any  LISP  data  structure  as  its  argument  causes  that 
argument  to  be  regarded  as  code  and  executed.  However*  most 
LISP  systems  include  a compiler  which  will  prodjce 

stand-alone  machine  code  for  interpreted  functions. 
Typically,  compilation  provides  an  order  of  magnitude 
speedup  which  makes  LISP  competitive  with  other  c omp i led 
languages*  or  even  with  well-coded  assembly  language.  Since 
interpreted  and  compiled  code  may  be  intermixed,  it  is 
possiole  to  retain  the  flexibility  and  power  of  the 
interpreter,  while  obtaining  the  speed  required  for 
production  applications. 

(5)  LISP  remains  recursive,  while  also  accommodating  iterative 
algorithms  via  a so-called  PROG  feature,  both  recursion  and 
iterative  programming  are  illustrated  in  subsequent 

sections. 

(6)  Because  of  the  technique  LISP  uses  in  storing  local  and 

global  variables,  some  very  powerful  context-switching  can 
e carried  out,  providing  a fast  way  to  enter  and  exit 
hypothetical  planning  environments  and  to  cause  the 
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4 .4" 
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behavior  of  a program  to  vary  as  a function  of  its 
environmental  context. 


3.1.1.  LISE  fern  iicv;£iuE£ 

LlSP's  data  structure«  called  the  S-expres s i on * is  simple*  yet 
extraordinarily  flexible*  providing  a substrate  upcn  which  a programmer 
may  design  his  own  complex  data  structures.  An  5-expression  is  either 
an  "atom"  or  a "CONS  node".  An  atom  can  be  regarded  as  eitner  a 
variaole,  a constant  (a  passive  symbol)*  or  both.  There  are  no 
declarations  in  LISP;  new  atoms  are  simply  admitted  to  the  system  .s 
they  are  scanneo  at  the  input  level*  and  atoms  with  the  same  name  are 
guaranteeo  by  the  system  to  be  unique  (i.e.*  they  have  the  same 
internal  pointer,  or  address). 

The  other  type  of  S-expression,  the  CONS  node*  provides  a means  of 
structuring  atoms  and  other  CONS  nodes  into  hierarchical  data 
structures.  A CONS  node  is  ordinarily  implemented  as  a single  computer 
word  (say,  36  bits  long)  which  contains  a left  pointer*  calteo  its  CAK, 
and  a riant  pointer,  called  its  CDR.  CONS  nodes  are  created  dynamically 
via  the  function  (CONa  X Y),  where  X ano  Y are  any  other  S -express i cns * 
or  passively  (as  oata  constants)  via  the  construction  (X.Y).  CONS  nodes 
can  be  composed  to  form  arbitrarily  complex  hierarchies,  the  bottommost 
elements  of  which  are  usually  atoms  (i.e.*  pointers  to  atomic 
S-express ions) • 

To  illustrate*  suppose  we  wish  to  represent  a particular  tool*  So> 
a screworiver*  in  a LISP  data  structure,  we  first  decide  upon  a name 
for  it,  say,  SC  KEwDklVER-1 * and  what  characteristics  of  it  we  wish  to 
encode.  Let  us  suppose  the  characteristics  are:  type  is  Phillips*  col.r 
is  yellow*  shaft  length  is  10  centimeters*  and  head  site  is  0.2 
centimeter.  There  are  many  ways  to  encode  this  in  LISP;  the  external 
representation  of  the  one  we  adopt  here  is: 


((NAME  SCREWDRI VER-1 ) 
(TOOL-TYPE  SCREWDRIVER) 
(STYLE  PHILLIPS) 
(SHAFT-LENGTH  10  CM) 
(COLOR-CODING  YELLOw) 
(HEAD-SIZE  0.2  CM)) 


Here,  all  symbols  such  as  NAME,  YELLOW,  etc.  are  LISP  atoms.  (So  too 
are  the  numbers;  however  numbers  are  not  entirely  equivalent  with 
symbolic  atoms.)  The  particular  hierarchy  we  have  adopted  is  a list  of 
lists*  where  each  sub-list  consists  of  an  initial  atom  describing  that 
sub -list's  role  in  the  structure*  and  a list  of  the  information 
associated  with  that  role  in  the  description. 

This  structure  would  be  graphically  represented  as  follows: 
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and  could  be  constructed  passively  (as  a fully  constant  structure)  vii 
a quoted  S-exp res sion : 


((NAME  SCRE  WDRIVER-1 ) (TOOL-TYPE  SCREWDRIVER)  ...) 


or  dynamically  via  COnS  : 


(CONS  (CONi,  'NAME  (CONS  'S C REWDR I VE R-1  NIL)) 

(CONS  'TOOL-TYPE  (CONS  'SCREWDRIVER  NIL)) 

(CONS  'HEAD-SIZE  (CONS  0.3  (CONS  'CM  NIL))) 


Since  It  would  be  a rather  harrowing  experience  to  construct  very  large 
S-expr essions  dynamically  in  this  fashion,  LISP  provides  a spectrum  of 
higher-level  functions  for  constructing,  modifying  ano  accessing 
S-express ions.  Some  highlights  of  these  will  be  covered  briefly  in  a 
subsequent  section.  For  our  example,  a more  concise  expression  of  cooe 
which  would  build  this  structure  dynamically  would  be: 


(LIST  (LIST  'NAME  'S  CRE  WDR  I VER -1  ) 

(LIST  'TOOL-TYPE  'SCREWDRIVER) 

(LIST  'HEAD-SIZE  0.3  'CM) 


Presumably,  having  defined  this  tool,  we  would  want  to  record  it 
as  one  available  tool  in  a large  supply  of  tools.-  Again,  there  would  be 
numerous  methods  of  doing  this.  One  way  would  simply  be  to  maintain  a 
global  list  of  all  known  tools  in  the  system,  and  to  add  this  entire 
description  as  a new  tool  on  this  list: 


(SETO  NEW-T00L  '((NAME  SCREWDRIVER-1)  (TOOL-TYPE  SCREWDRIVER)  ...)) 
(SETO  MASTER-TOOL -LIST  (CONS  NEW-T00L  MAST ER-T00L -L IS T )) 


(SETO  is  one  of  LISP  S assignment  statements.)  Alternatively,  we  might 
wish  to  put  only  the  name  of  the  screwdriver  on  the  master  tool  list, 
and  associate  all  the  remaining  information  with  property  DESCRIPTION 
on  SCREWDRIVER-1' s fc£fiCt£l¥  illi! 


.j. ■.  - . -..■j.v 
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(PUT  'SC REwDRI VER-1  'DESCRIPTION 

'•((  TOOL -TYPE  SCREWDRIVER)  ...  (HEAD-SIZE  G.2  CM))> 

(SET3  KASTtR-TOOL-LIST  (CONS  ' S CR E W DR  I V E R -1  MAST  ER-TOOL-L 1ST)) 


2.1.2.  P rgger yjsts 

Any  LISP  atom  may  have  a property  list  (built  up  from  CONS  nodes). 
Conceptually,  the  property  list  allows  the  attachment  of  an  arbitrary 
number  of  at t r i bute -va  lue  pairs  to  the  atom,  thereby  serving  to 
describe  the  c har ac te ri sti c s of  the  real-world  entity  represented  Ly 
the  atom.  This  is  a powerful  feature  for  any  programming  language, 
since  it  allows  "micro-descriptions"  of  atoms  which  ordinarily  will  net 
be  seer  by  the  processes  that  manipulate  the  hierarchical  structures  in 
which  the  atom  participates.  These  m i c r ode s c r i pt i ens  can  be  maintained 
and  accessed  by  the  functions  PUT,  GET  and  REKPRGP  in  case  more  aetail 
about  an  atom  is  oesired. 

Properties  are  attached  to  an  atom  via  the  function  (PUT  <atcm> 
<attrifcute>  <value>),  looked  up  via  (GET  <atom>  <at t ri bute>) , and 
removed  via  (REMPhOP  <atom>  <attribute>).  We  have  seen  one  way  to 
associate  -the  screwuriver  information  with  the  atom  S C REWD RI VE P -1  usin* 
property  lists.  Another,  more  convenient  way  would  be  to  split  apart 
all  the  various  attributes  of  this  atom,  making  each  a different  entry 
on  the  property  list: 


(POT  'SCREWDRIVER-1 
(PUT  'SCREWDRIVER-1 

(PUT  'SCREWDRIVER-1 


'TOOL-TYPE  'SCREWDRIVER) 
STYLE  'PHILLIPS) 

'HEAD-SIZE  ' ( C . : CM)) 


To  determine  SCRtWDRIVER-1's  head  size,  we  would  then  write:  (CLT 
'SCREWOkI VER-1  'hEAD-SIZc).  If  such  an  attribute  of  SC REWDRI VE R-1 
exists,  it  will  be  located  and  returned. 


3.1.3.  ££l2££S£0l£!lK£  L££P  £ata  Stru££y££  24QiB«UtiQa  EyQtliCQS. 

we  include  here  a definition  and  brief  example  of  several  of  the 
more  stanaardj  high-level  LISP  functions  that  pertain  to  data  structure 
creation,  mooification  and  searching. 


3 .1 .3. 1 . (HESEiJLR  2 11 

If  S-expression  X is  a member  of  S-expression  Y (assumed  to  be  a 
list),  return  "TRUE",  otherwise,  return  "FALSE". 

EXAMPLE:  (MEM3ER  'SCR EWORI VER-1  M A STER-TOO L-LI ST ) returns  a pointer  to 
the  atom  T ("true")  if  SCREWDR 1VER-1  is  on  the 
MASTt R-TOOL-LI ST,  and  a pointer  to  the  atom  NIL  ("false") 
otherwise. 
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3. 1.3. 2.  ms fit  i 12 

Y is  a list  of  lists.  Y is  scanned,  comparing  the  first  item  of 
each  sublist  to  X until  a match  is  found,  or  until  V is  exhausted.  In 
case  a match  is  founo,  ASSOC  returns  the  entire  sublist  whose  first 
i tern  mite  hed  X • 

EXAMPLE:  (ASSOC  'HEAD-SIZE  '((NAME  SCREWDRIVER-1)  ...  (HEAD-SIZE  C.3 
CM)))  woulc  return  the  sublist  (HEAD-SIZE  0.2  CM). 


3. 1.3. 3.  ( SU^ST  X Y Z) 

x,  Y and  Z are  arbitrary  S-express ions.  SU6ST  creates  a new  copy 
of  Z,  where  all  occurrences  of  Y in  Z are  replaced  with  X s. 

EXAMPLE:  (sues!  0.2  3.3  '((NAME  SCREWDRIVER-1)  ...  (HEAD-SIZt  C ,1 
CM)))  would  produce  a new  structure  for  our  screwdriver, 
identical  in  all  respects  to  the  original,  except  that  its 
head  width  would  be  0.2  instead  of  3.3. 


3. 1.3. 4.  (AEEEtlB  X 11 

X and  Y are  lists.  A new  list  is  created  which  is  the  result  of 
appending  Y onto  the  end  of  X. 

EXAMPLE:  (APPEND  '((NAME  SCREWDRIVER-1)  (STYLE  PHILLIPS))  '(( COLOR -C OD E 
YELLOW)  (HEAD-SIZE  0.3  CM)))  would  produce  ((NAME 

SCREWDRIVER-1)  (STYLE  PHILLIPS)  (COLOR-CODE  YELLOW)  (HEAD-SIZE 
0.3  CM)) 


3.1.4.  LISP  Dan  J£B££ 

In  addition  to  atoms  and  CONS  nodes,  most  LISP  systems  include  the 
following  other  data  types: 


1.  integer  numbers 
2 • rea l numbers 

3.  strings 

4.  arrays 

5.  octal  numbers  (for  bit-level  manipulations) 


Some  versions  of  LISP  (notably  MACLISP  EMoon743)  have  highly  developed 
numerical  and  trigonometric  facilities  and  accompanying  optimizing 
compilers  geared  to  the  efficient  generation  of  "number  crunching" 
sof twa re. 


3.1.5.  LISE  £ WQ£lifiD£ 

A LISP  "program"  is  a collection  of  functions.  No  function  is 
syntactically  declared  as  the  "main  program".  Functions  are  generally 
typeless  (i.e..  no  distinction  such  as  "integer",  "real",  "string", 
etc.  is  made).  However,  each  function  may  be  declared  so  that  its 
calling  arguments  are  passed  to  it  either  evaluated  (as  in  most 
programming  languages),  or  unevaluated.  Except  for  this  distinction, 
there  is  no  need  for  function-related  declarations. 
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A function  is  regarded  as  simply  another  type  of  data.  As  such* 
one  typically  defines  a function  by  assigning  to  some  atom  the  function 
as  the  atom  s value.  Strictly  speaking*  the  function  itself  is 
nameless*  and  is  identified  by  the  form: 


(LAMBDA  <argument- l ist>  <body>> 


When  e "lambda  expression"  is  stored  as  the  value  of  an  atom*  we  say 
that  a function  has  oeen  defined.  Although  the  implementation  details 
governing  how  a lambda  expression  comes  to  be  associateo  with  an  atom 
vary  considerably*  one  common  format  for  defining  a function  in  LISP 
i s : 


(DEFUN  <name>  <arguments>  <body>> 


DEFUN  is  a macro  which  creates  the  appropriate  lambda  expression  ana 
assigns  it  to  the  atom  <name>  as  the  function's  body.  A function  may  oe 
annihilated  or  altereo  simply  by  reassigning  the  value  of  the  atom 
which  represents  it.  Another  virtue  of  this  separability  of  a function 
from  its  name  is  that  nameless  functions  can  oe  created  and  passed  *.  s 
arguments  to  other  functions  without  having  to  oother  to  name  them  if 
they  are  needed  only  once. 

To  illustrate  LISP  functions*  let  us  define  a function  of  t»o 
arguments*  (LOCATE-AlL  <tool-type>  < too  l- l i s t >> * which,  given  the  name 
of  a tool  type  (e.g.*  SCREWDRIVER)*  and  a master  tool  list*  will  search 
the  tool  list  for  tools  of  the  specified  type  and  report  back  a list  of 
all  tools  of  that  type  it  finds.  Framing  this  as  a recursive  function* 
we  write: 


(DEFUN  LOCATE-ALL  (TYPE  MASTER-LIST) 

(COND  ((NULL  MASTER-LIST)  NIL) 

( (EQUAL  (GET  (CAR  MASTER-LIST)  'TOOL-TYPE)  TYPE) 
(CONS  (CAR  MASTER-LIST) 

(LOCATE-ALL  TYPE  (C  DR  M AS T ER -L I ST ) ) ) ) 

(T  (lOCATE-ALL  TYPE  (CDR  MASTER-LIST))).)) 


that  is*  if  (COND)  the  master  list  is  (or  has  been  reduced  to)  ML* 
then  report  back  "nothing";  otherwise*  if  the  next  item  on  the  master 
list  (its  CAR)  is  of  the  correct  type  (as  determined  by  the  GET),  then 
add  this  tool  to  the  list  to  be  reported  (i.e.,  CONS  it  onto  the  front 
of  this  list)  and  proceed  with  the  search  on  the  remainder  of  the  list 
(its  CDR);  otherwise  (T...)*  simply  proceed*  without  recording  the 
current  tool. 

Alternatively*  we  could  express  this  algorithm  in  iterative  form 
via  the  PkOG  feature: 


(DEFUN  LOCATE-ALL  (TYPE  MASTER-LIST) 

(PROG  (RESUuT) 

LOOP  (COND  ((NULL  MASTER-LIST)  (RETURN  RESULT)) 

((EQUAL  (GET  (CAR  MASTER-LIST)  “00L  -TYPE)  TYPE) 
(SETQ  RESULT  (CONS  (CAR  MASTER-LIST)  RESULT)))) 
(SETw  MASTER-LIST  (CDR  MASTER-LIST)) 

(GO  LOOP))) 


i.e.,  enter  a PROG  (akin  to  an  ALGOL  begin-end  block),  defining  one 
temporary  local  variable*  RESULT;  then*  while  the  master-list  remains 
non-nil,  repeatedly  examine  its  next  item,  collecting  those  with  the 
correct  type  on  the  RESULT  list  (via  SETQ,  LISP's  "assignment 
statement"),  scanning  to  the  next  tool  on  the  master  list  (SETQ 
MASTER-LIST  (CDR  MASTE R -LI S T ) ) . 
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2.1  . 6 • The  PROG 

As  just  Illustrated.  LISP  ac commoda te s i terat  ive ly-ph ra $co 
algorithms  via  a construction  called  a "PROG".  A PROG  has  the  form: 

(PROG  < loc a l- va ri ab les>  <statement-1>  ...  <s t atement-n>) 


y)  are  allocates  for 
t i zed  to  MIL.  Next,  the 
sequentially  executes 
the  bottom"  of  the  PROG 
a GO  or  RETURN  is 
interpreted  as  labels 
execution.  When  a GO 
occurs,  and  sequential 


As  a PROG  is  entereu,  the  local  variables  (if  an 
the  scope  of  the  PROG,  and  each  is  initia 
statements  which  comprise  the  PROB's  body  are 
(evaluatea)  until  execution  either  "falls  off 
(an  implicit  exit  from  the  PROG),  or  until 
encountered.  Statements  which  are  atoms  are 
within  a PROG,  ano  are  ignored  during  sequential 
is  encountered,  a branch  to  the  specified  lapel 
execution  proceeds  from  that  point. 

Since  a PROG  introduces  some  temporary  variables  which  must  te 
reclaimed  as  the  PROG  is  exited,  the  re  must  be  some  way  of  informing 
LISP  that  a PROG  is  aoout  to  be  exited.  The  function  RETURN  is  used  for 
this  purpose,  informing  the  system  that  a PROG  is  being  exited,  and 
specifying  what  value  the  PROG  is  to  return  to  the  calling  environment. 

PROG's  may  be  nested  and  may  appear  at  any  point  in  a LISP 
program.  The  PROG  construction  will  typically  result  in  a more 
efficient  implementation  of  an  algorithm  than  the  co r re spono i ng 

recursive  implementation.  Although  some  feel  that  PROG  makes  LISP 
"impure",  it  is  in  reality  the  feature  which  is  probably  most 
responsible  for  LISP  s present  widespread  acceptance  in  both  the  Al 
community  and  elsewhere. 


3.1.7.  LISE  atfiLfiS 

Most  LISP  implementations  support  two  types  of  macros: 
compile-time  macros  and  scanner  macros.  A compile-time  macro  is  nothing 
more  than  a function  which,  when  evaluated.  computes  not  a final 
result,  but  another  S-expression  which,  when  evaluated,  will  compute  a 
final  result.  Thus,  when  a macro  is  encountered  by  the  LISP 
interpreter,  a dsyfele  evaluation  is  performed  (the  first  to  compute  the 
intermediate  form,  tne  second  to  run  the  intermediate  form).  When  LISP 
functions  are  compiled  into  actual  machine  code,  the  compiler 
recognizes  macros  and  evaluates  them  once  to  obtain  the  intermediate 
form  which  it  then  compiles.  This  technique  is  a very  general  and 
powerful  implementation  of  the  macro  concept. 

Most  LISP  scanners  are  quite  modular,  in  the  sense  that  they  can 
be  conditioned  to  initiate  an  arbitrary  computation  upon  encountering  a 
given  character  in  the  input  stream.  For  example,  in  Wisconsin  LISP 
LNorman69jt  there  exists  a facility  called  (READMAC  <char>  <function>), 
which  conuitions  the  scanner  to  call  <function>  (no  arguments)  whenever 
<char>  is  aetecteu  in  the  input  stream.  <function>  is  free  to  perform 
any  computation,  and  whatever  <function>  returns  is  spliced  into  the 
scanner's  input  stream.  This  style  of  table-driven  scanner  makes  it 
possible  to  superimpose  additional  syntax  on  LISP  input,  even  to  the 
point  where  LISP  can  model  another  language's  syntax  (by  redefining 
delimiters,  etc.).  MLISP  CSmith70D  is  an  example  of  this. 


3.1.8.  ¥s£ia&.i£  steeiQii 

LISP  variable  values  are  derived  as  a function  of  the  run-time 
environment  rather  than  as  a function  of  lexical  environment.  As  a 
program  executes,  there  are  two  times  at  which  new  variables  are 
introduced,  or  "bound":  (1)  at  function  entry  time  (these  are  the  names 
of  the  function  s arguments  that  are  mentioned  in  the  LAMBDA 
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expression)*  and  (2)  at  PROG  entry  tine  (i.e.,  the  PROG  s temporary 
variables).  Variables  are  "unbound"  at  the  corresponding  exit  times: 
when  a function  returns  or  when  a PROG  is  exited. 

At  the  "top-level",  of  LISP  (when  no  function  is  currently 
executing)*  any  variables  which  receive  values  are  thought  of  «s 
"global"  to  the  system.  Therefore*  at  any  given  moment  curing 
execution*  there  will  be  a pool  of  global  atoms  plus  all  the  atoms 
introduceo  via  LAMBDA  or  PROG  on  the  current  sequence  of  function 
calls.  All  these  variables  and  their  associates  values  ("bindings")  are 
recordeo  on  a structure  callea  the  "association  list"  (A-LIST),  a 
user-accessible  list  of  CONS  nodes.  All  variable  lookups  consult  this 
list,  from  most  recent  to  least  recent.  Since  this  list  is  dynamically 
maintained  at  run-time,  the  question  of  what  variables  are  and  are  not 
bound  (i.e.,  are  on  the  A-LIST)  is  exclusively  determined  oy  the 
dynamic  calling  environment,  rather  than  the  lexical  scope  of  variables 
at  the  time  functions  were  defined.  This  means  that  "free"  variables 
(ones  which  have  no  binding  at  the  current  level)  will  assume  a value 
at  run-time  which  is  dependent  upon  their  definitions  in  functions 
farther  up  the  calling  hierarchy.  In  this  manner,  one  function  "peeks 
into",  or  borrows  the  variables  of  another. 

by  changing  the  system's  A-LIST  pointer  while  inside  a function, 
that  function's  entire  environment  can  be  altered.  For  this  reason, 
LISP  is  a very  powerful  tool  wherever  hypothetical  reasoning  (involving 
switches  to  altered  contexts)  is  necessary.  Most  other  languages  either 
lack  such  an  ability,  or  make  it  difficult  to  carry  out.  In  LISF, 
context  Switching  and  "taking  snapshots"  of  contexts  to  which  execution 
is  to  be  returned  are  very  natural  operations. 


3.1.9.  tl£P  I/O 

Traditionally,  input/output  has  been  LISP's  weakest  link.  Most 
systems  define  at  least  the  following  I/O-related  functions: 


(READ)  read  an  S-expression 
(READCH)  read  an  individual  character 

(PRINT  X)  print  S-expression  X,  skipping  to  a new  line 
(PRINl  X)  print  S-expression  X on  the  current  output  line 
(TERPRI)  skip  to  beginning  of  new  line  on  output 


While  these  functions  provide  adequate  formatting  control,  most  LlSFs 
are  deficient  in  f i l e-hand  l i no  operations.  (INTERLISP  CTe  ite  lman743  is 
the  exception,  with  more  highly  developed  interfaces  to  the  TENEX 
virtual  operating  system).  We  regard  this  deficiency  as  more  of  a 
historical  accident  than  as  an  inherent  problem  of  LISP  (since  adding 
these  features  is  simply  a matter  of  writing  the  code).  In  fact,  there 
are  efforts  underway  for  improved  mu l ti p le - fi l e interaction  and  rancom 
access  facilities  both  at  Ml T (MACLISP)  ana  at  Maryland  (Wisconsin 
LISP). 


3.1.10.  Gtrfetae  Cgiietlien 

Since  LISP  data  structures  can  grow  in  unrestricted  ways,  a 
crucial  part  of  any  LISP  system  is  a conceptually  asynchronous  process 
called  tne  "garbage  collector".  The  role  of  this  process  is 

periodically  to  take  control,  mark  parts  of  storage  that  are  still 
referenced  by  the  ongoing  computation,  then  reclaim  all  storage  that  is 
not  so  referenced  (garbage).  Garbage  collection  is  an  unavoidable 
overhead  of  any  system  with  no  declarations,  and  in  which  aata 
structures  can  grow  in  unrestricted  ways. 

une  potential  disadvantage  of  garbage  collection  is  that,  once  the 
system  runs  out  of  free  storage,  a garbage  collection  muji  occur. 


Since  a garbage  collect  causes  current  computing  activity  to  be 
suspended,  if  LISP  is  controlling  a real-time  process*  disastrous 
consequincs  can  accrue*  Such  problems  can  normally  be  avoided  by 
forcing  the  system  into  a premature  garbage  collect  prior  to  entering 
real-time  critical  sections  of  computation.  Alternatively*  there  is 
growing  interest  in  truly  asynchronous  (parallel)  garbage  collection 
techniques  t*hich  could  obviate  the  problem  altogether  (see  L Di  j kst  ra7L  3 
for  instance). 
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3.1.11.  Li£P  as  a Se  ±.f  n n e 

LISP  interpreters  are  typically  implemented  in  assembly  language. 
After  this  basic  facility  has  been  brought  up*  most  other  suppurting 
software  can  be  written  in  LISP  itself.  Typical  software  includes 

(1)  A gojciisi  which  will  generate  (potentially  quite  gooo) 
machine  code  for  LAMBDA  expressions  (i.e.,  functions)  and 
P«06s.  Typically*  the  LISP  compiler  will  be  written  in 
interpreted  LISP*  then  used  to  compile  itself.  The  compiled 
version  is  subsequently  used  as  the  LISP  system  compiler. 

(c)  A debug  package  which  will  permit  the  tracing  and 
interactive  “He veTopment  of  functions.  Typically*  functions 
(together  with  their  calling  arguments)  can  be  traced  at 
entry  time*  and  (together  with  their  returned  values)  at 
return  time.  Most  LISPs  will  also  accommodate  the  tra-ing 
of  variables  (i.e.*  inform  the  user  whenever  a traced 
variable  s value  is  about  to  be  changed).  The  debugging 
potentials  of  LISP  are  essentially  unlimited  (the  INTERLISP 
system  is  the  most  advanced  to  date)*  and  are  responsible 
(in  part)  for  LISP  s reputation  as  one  of  the  best 
languages  for  the  efficient  and  rapid  development  of 
complex  software.  In  particular*  there  is  no  time-consuming 
interaction  with  system  compilers*  loaders  and  linkers  to 
be  contended  with;  a program  can  be  developed  and  put  into 
production  within  the  confines  of  the  LISP  system  itself. 

(3)  An  S-expression  editgr  (or  system  editor  interface)  which 
makes  possible  ffie'convenient  editing  of  S-e xpre s si ons  and 
maintenance  of  files. 


While  LISP  is  generally  accepted  as  the  standard  for  computing  in 
AI*  it  does  not  supply  the  user  with  any  a-priori  conceptions  aoout 
intelligence.  LISP  is  simply  the  blank  tablet  onto  which  the  user  must 
write  nis  theory  of  Intelligence  or  control.  Not  surprisingly,  this 
resulted  in  numerous  reinventions  of  the  wheel  in  areas  like  database 
organization*  problem  solving*  hypothetical  reasoning*  and  language 
understanding.  Most  reinventions  were  at  a fairly  low  level*  but 
occurred  often  enough  to  warrant  some  investigations  into  some  of  the 
undercurrents  of  AI  programming  techniques. 

MICROPLANNER  CSussman,  winograd,  Charniak  713  is  the  outcropping 
of  some  of  these  undercurrents*  particularly  where  automatic  problem 
solving  is  concerned.  MICROPLANNER  was  written  in  1970-71  as  a 
small-scale  implementation  of  ideas  originally  proposed  by  Hewitt  in 
1969  CHewitt693.  The  intent  of  the  language  was  and  is  to  provide  some 
automatic  mechanisms  of  database  organization*  context*  and  heuristic 
search. 

MICROPLANNER  is  implemented  entirely  in  LISP.  Because  of  this*  its 
syntax  is  essentially  LISP's  syntax*  and  while  in  the  MICROPLANNER 
environment,  the  user  has  full  access  to  all  of  LISP.  To  distinguish 
MICROPLANNER  (hereafter  abbreviated  MP)  functions  from  pure  LISP 
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functions,  the  convention  is  to  prefix  all  MR  functions  (there  art 
about  50  of  them)  with  "TH"  (standing,  we  presume,  for  “theorem",  a kty 
notion  in  MP). 

The  most  salient  features  of  MP  are  these: 

(1)  Computation  in  MP  is  induced  by  pattern,  rather  than  oy 
Celling  functions  by  their  names.  In  this  style  of 
computation  (often  called  "pattern-directed  invocation"), 
whenever  a goal  requires  solution,  a pattern  describing  the 
goal  is  posted  to  the  entire  system.  "Entire  system" 
normally  means  a large  population  of  problem-solving 

experts  with  patterns  which  advertise  each  one's  expertise. 
Whenever  a need  is  posted,  the  system  searches  through  the 
database  of  experts  looking  for  those  whose  advertised 
patterns  match  the  need.  Each  expert  so  located  is  then 
tried  in  turn  until  one  succeeds,  or  until  all  have  faileo. 

This  is  a radically  different  computing  paradiqm  from  the 
standaro  paradigm  of  "name  calling",  since  it  makes  for  a 
vtry  modular  system  where  the  requestor  needn't  know  any 
experts  cy  name;  problems  are  solved  by  anonymous  experts 
in  the  population  at  large. 
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(Z)  Mr  automatically  maintains  a context-sensitive  database  of 
both  factual  assertions  and  the  experts  just  mentioned.  The 
factual  database  is  a collection  of  highly  indexed 
n-tuplest  expressed  as  L13P  S-e xpr e ss i on s . Any  one  n-tuple 
("assertion"),  or  collection  of  n^tuples  can  oe 

" as soc iat i ve ly"  accessed  by  presenting  the  lookup  routines 
with  a pattern  containing  zero  or  more  variables.  Only 
those  facts  that  are  deemed  active  in  the  current 

"context",  regardless  of  whether  they  physically  exist  in 
the  memory,  will  be  located. 

(3)  MP  ooes  all  the  bookkeeping  required  for  depth-first, 
nonoet e rm inis ti c programming.  That  is,  anytime  there  is  a 
decision  of  any  sort  in  MP,  the  system  makes  a choice 
(either  arbitrarily,  or  under  the  control  of  user-specified 
heuristics),  records  the  alternatives  for  possible  future 
reference,  and  then  proceeds.  If  a failure  ever  causes  a 
"backup"  to  that  decision  point,  the  system  automatically 
discards  the  current  (failing)  choice,  selects  the  next 
alternative,  and  then  attemots  to  proceed  again.  In  tne 
backup  process,  all  computations  performed  between  the 
initial  (bud)  choice  and  the  failure  point  are  undone  (a 
record  of  all  changes  to  the  database  is  maintaineo),  and 
the  system  picks  up  from  the  decision  point  as  though 
nothing  hud  ever  gone  wrong.  Thus,  MP  can  be  said  to 
maintain,  at  least  implicitly,  an  entire  goal  tree  (search 
tree)  for  each  problem  it  attempts  to  solve.  As  we  will 
suggest  later,  there  are  both  advantages  and  disadvantages 
to  such  automatic  control. 


These  are  the  three  main  contributions  of  mp.  in  the  following 
sections  we  highlight  and  illustrate  some  of  the  specific  features  ot 
this  problem  solving  language. 


3.2.1.  The  Ml CRO P^ANhER  Database 

• 

Conceptually,  the  MP  database  is  divided  into  two  segments:  facts 

and  theorems.  Theorems  are  further  classified  into  three  categories: 
"antecedent"  theorems,  "erasing"  theorems/  and  "consequent"  theorems. 
Theorems  are  discussed  in  section  3.2.2. 

Both  facts  and  theorems  are  entered  into  the  database  via  the 
function  THASSERT;  an  item  is  deleted  from  the  database  via  the 
function  THERASE.  Facts  are  f u l l y -c ons t an t LISP  n-tuples.  Thus,  to 
represent  our  screwdriver  in  MP,  we  might  augment  the  database  as 


.i  urn.  Jii>i  ninui  ii.i.h  ■i-ii  i miu).  iwij  i.miuL  iiiiwuw  i 


f ol low  s : 


(THASSERT  (TOOL-TYPE  S C K EW D RI V E R -1  SCREwDRIVER)) 
(THASSERT  (STYLE  S C R E U DR  I V E R- 1 PHILLIPS)) 

(THASSERT  (HEAD-SIZE  S C R EW D RI V ER -1  0.3  CM)) 


Database  lookups  and  fetches  are  accomplished  via  the  function 
TH60AL.  Therefore*  if  at  some  point  in  a MP  program*  we  required  a 
knowledge  of  S CRE wDRI VE R-1 ' s head  width*  we  could  write  a fetch  pattern 
of  the  form: 


(THGOAL  (HEAD-SIZE  S C R E W DR  I V ER -1  (TH  V X)  ( T H V Y))) 


f or  our  example*  this  would  respond  with  "success"  (i.e.*  a fact  which 
matched  this  template  was  located  in  the  database*  and  it  would  produce 
the  side  effects  of  binding  the  MP  variables  X and  Y to  0.3  and  Cf, 
respectively.  The  THV  form  is  used  in  MP  to  signal  references  to 
variaoles  (all  else  is  implicitly  constant). 

Every  fact  and  theorem  in  the  MP  database  has  a context  marking, 
whenever  a fact  or  theorem  is  THASSERTeo*  if  such  a fact  is  not  alreacy 
present  in  the  database*  it  is  created  and  then  marxed  as 
also  oeing  l22i£<*iiY  present.  If  the  THASSERTed  fact  is  present 
ohysically*  ~bu?  marked  as  logically  noi  present*  its  logical  status  is 
changed  to  "present".  If  the  fact  is  already  logically  and  physically 
present*  THASSERT  Poes  nothing*  cut  reports  a "failure"  to  store  a new 
copy  of  the  fact.  ThERASE  exerts  opposite  effects  on  facts  in  the 
database:  it  causes  a fact  to  be  logically  masked*  either  by  changing 

the  fact  s logical  context  marking,  or  by  actually  physically  deleting 
the  fact  (i.e.,  if  the  fact  is  being  THERASEd  at  the  level  at  which  it 
was  2EisiQlU*  THASSERTed). 

Context  markings  allow  MP  to  keep  track  of  the  history  of  the 
logical  status  of  each  fact  and  theorem.  This  enables  the  system  to 
back  up  to  prior  context  levels,  thereby  restoring  the  database  to  the 
corresponuing  prior  state.  Thus,  although  there  are  mechanisms  for 
makinB  permanent  oataoase  changes  (e.g.»  after  some  segment  of  mp  cooe 
is  confident  that  what  it  has  done  is  absolutely  correct),  normally 
(except  at  the  top  level)*  THASSERT's  and  THERASE 's  are  not  permanent; 
instead*  they  normally  exist  only  for  the  duration  of  some  stretch  of 
planning  or  hypothetical  reasoning. 


3.2.2.  {U£RCeU!lbE&  Ib£2r£!D£ 

All  reasoning  (in  fact*  all  computation)  in  MP  is  carried  out  by 
THANTE,  THERASINu,  and  THCONSE  "theorems"  which  are  called  by  pattern 
rather  than  by  name.  The  three  types  of  theorem  . are  indistinguishable 
in  internal  form*  except  with  regard  to  the  type  of  event  to  which  each 
responds.  A THANTE  theorem  is  triggered  by  the  THASSERTion  into  the 
factual  database  of  any  pattern  which  matches  its  invocation  pattern.  A 
ThERASING  theorem  is  triggered  by  the  THERASEure  from  the  database  of 
any  factual  pattern  which  matches  its  invocation  pattern.  In  the  sense 
that  these  two  classes  of  theorems  respono  spontaneously  (not  in 
response  to  any  particular  request),  they  represent  a general  interrupt 
capability.  A ThCONSE  theorem  responds  to  THGOAL  requests  whose  god 
patterns  match  its  invocation  pattern. 

Because  of  this  last  interaction  between  THGOAL 's  and  THCONSE*  a 
THGOAL  can  amount  to  considerately  more  than  a simple  database  fetch. 
In  MP*  when  a THGOAL  is  issued*  the  system  first  attempts  to  locate  the 
desired  goal  directly  as  a fact  in  the  database.  If  this  fails*  and 
the  THGOAL  request  has  indicated  that  it  is  permissible  to  do  so*  MP 
will  begin  searching  for  THCONSE  theorems  whose  invocation  patterns 
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match  the  desired  9oal.  If  anv  are  found,  each  is  executed  in  turn 
until  one  reports  success  (in  which  case  the  THGOAL  is  satisfied), 
until  all  THCONgE  theorems  have  bailee  (in  which  case  the  THoC*L 
fails).  It  is  in  this  manner  that  more  complex  knowledge  (i.e., 
theorems,  problem  solving  techniques,  etc.)  can  he  automaticolly 
brought  tu  bear  on  some  goal  if  that  aoal  is  not  alreaay  explicitly 
present  in  the  factual  database. 

The  forms  of  these  three  MP  theorem  types  are: 


(THANTE  <opt i on  a l -n ame > <variables>  < i nv oc at  ion-pa 1 1 e rn>  <bcuy>) 
(THERASIN6  < opt iona l-name>  <variables>  < i nvo ca t i on-pa t t e rn>  <toay>) 
(THCGhSt  <op t i o na l-na me>  <variaoles>  < in voca t i on-pa t t e r n > <Lody>) 


As  a brief  illustration  of  the  uses  of  each  cf  these,  suppose  »t 
wish  to  implement  the  following  three  capabilities  in  MP  : (a)  whenever 
a new  screwdriver  is  oefined  to  the  system,  automatically  cause  its 
name  to  be  added  to  the  master  tool  list;  (6)  whenever  a screwdriver  is 
deleted  from  the  system,  automatically  remove  its  name  from  the  master 
tool  list,  and  also  remove  all  its  accompanying  information;  (c) 
whenever,  during  some  assembly  task,  a THGOAL  of  the  form:  (SCREw-lN 
<some  scrtw>  <some  threaded  hole>)  is  announced,  automatically  search 
for,  and  return  the  name  of  an  appropriate  screwdriver  for  the  task 
(baseo  on  the  screw's  style  and  heao  size).  Task  (a)  will  be  modelea  us 
a MP  THANTE  theorem,  part  (b)  by  a THERaSIKS  theorem,  and  part  (c)  oy  o 
THCONSE  theorem  as  follows: 


(THANTt  (X)  (TOOL-TYPE  ( THV  X)  SCREWDRIVER) 

(SETQ  MASTEk-TGOL-LIST  (CONS  (THV  X)  K A S TE R -TOO L-LI S T) ) ) 


(THERASING  (X)  (TOOL-TYPE  (THV  X)  SCREWDRIVER) 

(THPROG  (ST  CC  ...  HS  HSU) 

(SETQ  MASTER-TOOL-LIST  (DELETE  (THV  X)  M AS T ER -T 00 L -L I St ) ) 
(THAND  (THGOAL  (STYLE  (THV  X)  (THV  ST))) 

(THERASE  (STYLE  (THV  X)  (THV  ST)))) 

(THAND  (ThGOAL  (COLOR-CODE  (THV  X)  (THV  CC))) 

(TnERASE  (COLOR-CODE  (THV  X)  (THV  CC)))) 

(THAND  (TrtGGAu  (HEAD-SIZE  (THV  X)  (THV  HS)  (THV  HSU))) 

(ThERASE  (HEAD  -SIZE  (THV  X)  (THV  HS)  (THV  HSU)))))) 


(THCONSE  (SCREW  HOLE)  (SCREW-IN  (THV  SCREW)  (THV  HOLE)) 

(ThPROG  (ST  HS  HSU  DRIVER  DST  DHS  DHSU) 

(T hG OAv.  (STYLE  (THV  SCREW)  (THV  ST))) 

(ThGOAL  (HEAD-SIZE  (THV  HOLE)  (THV  HS)  (THV  HSU))) 

(ThGOAL  (TuOu-TYPE  (THV  DRIVER)  SCREWDRIVER)) 

(THAND  (THGOAL  (STYLE  (THV  DRIVER)  (THV  DST))) 

(EQUAL  (THV  DST)  (THV  ST))) 

(THAND  (THGOAL  (HEAD-SIZE  (THV  DRIVER)  (THV  DHS)  (THV  DHSU))) 
(EQuAl  (THV  DHS)  (THV  HS))) 

(THRETURN  (THV  DRIVER)))) 


3.2.3.  Heuristic  Guidance  of  I h e o re  m Application 

it  is  possible,  by  including  special  indicators  in  THGOAl, 
THASSERT  and  THERASE  calls*  to  influence  the  order  in  which  theoreius 
are  applied,  or  in  fact  to  indicate  whether  or  not  they  should  be 
applied  at  all.  Specifically,  a THGOAL  (similar  remarks  apply  to 
THASSERT  «no  THERASE)  with  Qg  indicators  will  fail  unless  the  requestto 


20 


goal  can  be  satisfied  exclusively  by  database  fetches  (no  theorems  bill 
be  applieo).  (This  is  the  form  we  nave  been  using  for  illustration 
purposes.)  If  the  re  is  an  indicator  present,  it  has  either  the  form  of 
a “filter"  or  a specific  “recommendation  list"  of  theorems  (referenced 
by  name).  When  a filter  is  included  in  a THGOAL  request,  only  those 
theorems  whose  properties  pass  the  filtering  test  (theorems  can  possess 
property  lists)  will  oe  candidates  for  application.  if  the  indicator 
has  the  form  of  a specific  recommendation  list,  all  theorems  on  that 
list  will  be  applieo  first  (in  order)  before  any  other  theorems  from 
the  9eneral  theorem  base  are  attempted.  Both  forms  allow  the  programmer 
to  insert  limited  heuristic  influences.  Also,  since  one  MP  theorem  can 
create  or  modify  another  MP  theorem,  the  filter  facility  provides  a 
setting  in  which  a collection  of  theorems  themselves  can  evolve  into  a 
more  structured  configuration  on  the  oasis  of  past  experience  (e.g., 
who  in  the  past  has  proven  to  oe  the  most  reliable  expert).  Althcuv,n 
filtering  and  recommendations  are  a step  in  the  right  direction,  as 
will  discuss  later,  CONNIVER  provides  a more  flexible  environment  in 
which  to  encode  heuristic  knowledge. 


3.2.0.  Si»££!>i09  and  fiatkyc  Id  £!E 

Search  and  backup  in  MP  can  occur  for  two  reasons:  (1)  son. t 
THCONSE  theorem  which  was  run  to  accomplish  a THGOAL  fails,  and  another 
theorem  must  oe  invoked  (restoring  the  environment  to  the  state  at 
which  the  first  theorem  took  over),  or  (2)  some  object  to  which  the 
system  has  committee  itself  is  Discovered  to  be  inappropriate,  giving 
rise  to  the  need  of  locating  another  candidate  object  and  retrying. 
The  THGOAL-THCONSE  mechanism  underlie  the  selection  and  backup  where 
theorems  are  concerneo,  but  object  selection  is  handled  differently, 
via  the  THPROG  MP  construction. 

In  the  previous  THCONSE  example,  the  goal  was  to  locate  some 
screwdriver  which  satisfied  some  set  of  features  (in  that  case,  the 
correct  STYLE  and  HtAD-SIZE).  This  was  accomplished  by  a THPROG  which 
"conjectures"  that  such  an  object,  say  X,  exists,  then  proceeds  to 
determine  whether  or  not  this  conjecture  is  true.  In  the  example  above, 
the  THPROG  searched  for  a screwdriver  of  type  and  size  which  matched 
the  type  ana  size  of  the  particular  screw  which  was  to  be  inserted.  For 
the  sake  of  illustration,  suppose  the  screw  was  of  type  Phillips  of 
head  size  0.3.  Then,  the  THPROG  in  the  example  above  would  have 
performed  essentially  the  same  starch  as  the  followina,  more  specific, 
THPROG  : 


(THPROG  (X) 

(THGOAL  (TOOL-TYPE  (THV  X)  SCREWDRIVER)) 
(THGOAL  (STYLE  (THV  X)  PHILLIPS)) 

(THGOAL  (HEAD-SIZE  (THV  X)  G.3)) 
(THRETUkN  (THV  X))) 


i.e.,  introduce  an  initially  uncommitted  variable,  X,  to  represent  the 
object  being  searched  for.  First,  Obtain  a candidate  for  X fcy  finding 
an  object  which  is  of  TOOL-TYPE  SCREWDRIVER  (the  first  THGOAL  does 
this).  At  that  point,  X will  be  tentatively  bouno  to  the  first  such  an 
object  found.  Continue  with  this  candidate  until  either  all  THGOALs 
have  been  satisfied  (in  which  case,  the  candidate  is  a success),  or 
until  some  THGOAL  fails  (in  which  case,  the  system  must  back  up  and 
choose  another  candidate).  Since  some  objects  may  pass  the  first 
THGOAL,  or  even  two,  but  not  all  three,  the  system  must  automatically 
keep  track  of  whai  object  it  is  currently  considering,  and  what  other 
objects  remain  to  De  tested.  This  is  the  source  of  backups  which  are 
propagateo  because  of  bad  object  selections. 

To  keep  track  of  theorem  and  object  selection  backups,  MP 
maintains  a decision  tree,  THTREE,  which  is  essentially  a record  of 
every  decision  maoe,  ano  what  to  oo  in  case  the  decision  leads  to  a 
failure.  The  strength  of  THTREE  is,  of  course,  that  it  frees  the 
programmer  from  having  to  worry  aoout  failures:  if  there  is  a solutior, 
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it  will  eventually  be  found  by  an  exhaustive  search.  The  fatal  weakness 
of  THTREE  is  that  it  imposes  an  often  undesirable  depth -first  ordering 
on  the  search  (i.e.,  one  subgoal  must  be  solved  in  its  entirety  Defore 
any  other  subgoals  can  be  attacked).  This  makes  it  difficult,  if  not 
impossible,  to  fabricate  complexly  intertwined  solutions,  since 
subgoals  cannot  communicate  laterally  in  the  tree.  The  Me  organization 
is  also  quite  awkward  in  its  backup  technique  Decause  of  the 
depth-first  organization  of  THTREE.  Often,  one  small  failure  will  Cause 
an  entire  branch  of  THTREE  to  be  undone,  when  in  fact  most  of  it  wus 
correct.  It  would  be  more  desirable  to  be  able  to  discard  only  the  boO 
part  of  the  tree,  retaining  the  Darts  which  are  correct,  so  thot 
wholesale  resynthesis  of  large  parts  of  the  THTREE  does  not  have  to 
occur.  Unfortunately,  this  is,  again,  very  difficult,  if  not  impossible 
to  do  in  HP.  CONNiVER  has  a better  control  structure  in  these  respects. 


2.2.5.  Cib££  EfiB££5£Qtaiiy£  CoEabiiiiifis 

To  complete  o^r  description  of  MICROPLANNER,  we  include  t»o 
representatives  of  the  other  functions  available  in  this  language, 
together  with  a brief  example  of  each. 


3.2.5. 1.  iIHE  J.ND  <mo  o e > < y a r^ab  _l  e £>  <skel_>  <boay  > ) 

THFIMD  provides  a way  of  finding  all  objects  in  the  system  which 
satisfy  « certain  set  of  criteria.  A THFIHt  is  essentially  a THPRGt 
which  is  made  to  fail  artificially  after  each  successful  location  of  an 
object  which  satisfies  the  criteria.  <mode>  indicates  how  many  oojects 
are  to  be  locateo  (e.g.,  "ALL",  "(AT-LEAST  <c ount >)"••••)  ; <variables> 
serve  the  same  role  as  THPROG  variables;  <skel>  specifies  what  form  to 
return  as  each  object  is  found;  <body>  contains  the  TH60AL's,  etc. 
which  define  the  criteria.  THFIND  returns  either  a failure  (in  case 
<mode>  number  of  objects  could  not  be  found),  or  a list  of  <skel>'s, 
each  < s ke  l>  corresponding  to  one  successful  object  thus  found. 


EXAMPLE:  (THFIND  ALL  (X)  ( THV  X) 

(THGOAL  (TOOL-TYPE  (THV  X)  SC F EWOR I VE R ) ) 
(THGOAL  (STYLE  (THV  X)  PHILLIPS)) 


would  return  a list  of  all  toots  which  were  Phillips  screwdrivers. 


3. 2. 5.2.  ilHMESSAGE  <yarjab^es>  < pa t te  rn>  < bocy > ) 

As  subgoals  art  descended  into  (i.e.  "on  the  way  down"  the  goul 
tree),  THMESSAGE  statements  have  no  effect.  They  are  essentially 
"hooks"  which  will  intercept  failures  beneath  them  in  the  goal  tree  as 
such  failures  propagate  back  up  to  the  THMESSAGE  via  a (THFAIL 
THMESSAGE  <pwttern>).  Upon  bein3  backed  up  to  by  a THFAIL,  any 
THMESSAGE  whose  pattern  matches  the  THFAIL  pattern  will  take  control 
(its  <body>  will  oe  executed).  Thus,  the  THME SS A6 E-T H F AI L combination 
provides  a way  of  a Dli£ iBili Di  possible  problems  without  actually 
checking  for  them  beforehand.  IT  all  goes  well  beneath  the  THMESSAGt, 
it  will  never  run;  however,  if  someone  gets  into  trouble  beneath  the 
THMESSAGE  (in  some  way  the  THMESSAGE  is  prepared  for),  the  THMESSAGE 
can  correct  the  problem  and  then  cause  the  part  of  the  tree  beneath  it 
to  oe  reattempted. 
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EXAMPLE:  ...  (anticipate  difficulty  in  inserting  a screw) 

(THMESSAGE  (X  Y)  ( ( TH V X)  WILL  NOT  TURN  IN  (THV  Y>> 

(THGOAl  (LUBRICATE  ( TH V X)))  (attempt  a remedy) 

(THGOAl  (SCREW-IN  (THV  X)  (THV  Y))))  (retry) 


...  (attempt  to  insert  some  screw  in  some  hole) 

...  (report  a failure  back,  up  to  the  THMESSAGE) 

(THFAIL  TH MESSAGE  ((THV  SCREw)  WILL  NOT  TURN  IN 

(THV  HOLE))) 


would  anticipate,  detect*  report,  and  correct  a problem,  then  retry. 


3.3.  CONNIVER 

The  most  recent  stage  in  the  evolution  of  the  LISP  family  of 
languages  was  the  result  of  McDermott's  and  Sussman's  development  of  a 
language  called  CONNIVER  [McDermott,  Suss man  733.  CONNIVER  s 
development  was  principally  motivated  by  the  control  structure 
deficiencies  of  MP,  as  suggesteo  in  the  earlier  discussion  of  TnTREE. 
Although  there  were  some  improvements  in  the  database  and 
pattern-directed  invocation  control  (e.g.,  the  pattern  matcher  is  more 
sophisticated),  the  most  significant  feature  of  CONNIVER  is  its  ability 
to  maintain  numerous  computations  in  states  of  suspended  animation, 
then  to  switch  among  them,  working  or.  many  subgoals  or  alternate 
strateaies  in  unison  rather  than  one  at  a time.  In  such  an  environment, 
partial  computations  need  not  be  undone  simply  because  some  small 
aspect  of  the  problem  solving  has  gone  awry. 

CONNIVER  is  less  a programming  language  than  it  is  a collection  of 
ideas  about  control  structure.  (The  languaoe  apparently  has  never  been 
used  for  more  than  one  or  two  significant  programming  tasks 
C Fahlman73D ) . Because  of  this,  our  discussion  will  omit  most 
references  to  syntax,  and  highlight  only  the  aspects  of  CONNlVtR's 
control  structure  which  are  unusual  or  unique  to  it. 


3.3.1.  FtanifiSi  Aynevair  and  Adisy 

In  a conventional  programming,  language  (MP  included),  one  function 
calls  another  function  either  by  name  or  pattern  and  waits  until  the 
called  function  returns  control.  In  a conventional  language,  once  a 
function  returns,  that  copy  of  it  dies;  the  function  may  be  called 
anew,  but  the  new  call  will  cause  a new  "copy”  of  the  function  to 
begin.  No  memory  of  a function  s current  status  can  be  preserved  across 
call-return  sequences.  This  type  uf  control  is  usually  carried  out 
under  the  control  of  push-down  stacks  which  record  calling  arguments 
and  return  addresses;  calling  a function  causes  stacks  to  be  pushed, 
white  returning  from  a function  causes  stacks  to  be  poppeu, 
annihilating  all  control  information. 

In  CONNIVER,  things  are  quite  a bit  different.  To  call  a function 
in  CONNIVER  is  to  create  a so-called  "frame"  for  the  called  function, 
rather  than  to  push  information  onto  a central  stack.  A function's 
frame  will  contain  all  the  information  needed  to  characterize  the 
function  at  any  moment  (e.g»,  from  what  A-LIST  it  derives  values  for 
its  free  variable*,  to  whom  it  is  to  return  when  it  has  finisheo, 
etc.).  There  are  two  important  features  of  a frame.  First,  it  is  a 
user-accessible  LISP  data  structure.  This  means  that  a function  may 
alter  its  own  or  another  function  s frame  in  arbitrary  ways,  causing 
free  variables  to  be  looked  up  on  some  other  function's  A-LIST,  or 
causing  the  identity  of  the  function  to  which  control  is  to  be  returned 
to  be  altered.  Second,  because  there  is  no  central  stack  which  is 
chronologically  pushed  and  popped  at  function  entry/exit,  execution 
control  is  free  to  meander  from  one  function  to  the  next  without 
permanently  closin*  any  function.  Thus,  at  any  moment,  there  can  Le 
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numerous  suscendeo  functions  which  may  te  resumed  at  the  point  at  which 
they  last  relinquisheu  controli  or  in  fact*  at  an  arbitrary  labeled 
point  witnin  them. 

As  one  might  expect,  this  ability  makes  the  context  marxin 
technique  for  items  in  the  database  more  complex  than  in  in 

particular*  since  control  may  eventually  be  returned  to  any  suspended 
function  (the  system  in  general  has  no  way  of  knowinc  whether  or  not  it 
actually  will  te  ) * every  fact  in  the  database  must  have  markincs  which 
specify  fur  every  suspended  function.  F,  whether  or  not  that  fact  it 
supposed  to  be  logically  present  while  F is  running.  To  accomplish  this 
type  of  marking*  the  MP  context  scheme  was  generaliaeo  frotr.  ^ 
stack-like  arrangement  to  a tree  of  contexts.  r-osically,  every  fact 
lives  on  some  branch  of  the  tree*  and  functions  have  access  to  limbs  of 
the  tree.  Although  there  is  considerable  overhead,  the  system  mano-cs 
to  mask  and  unmask  facts  in  the  Database  in  synchrony  witn  the 
meandering  of  execution  control  from  one  function  to  the  next. 

To  distinguish  the  permanent  return  of  a function  from  the  case 
where  a function  merely  relinquishes  control,  reserving  the  option  to 
continue*  CONNIVER  oefines  two  methods  of  returning:  ADIEU  (final, 

permanent  return)  and  AU-REVOIR  (suspension).  One  very  important 
application  of  the  AU-REVOIR  feature  is  in  the  (often  costly) 
generation  of  alternatives.  Rather  than  calling  a Function  (Such  as 
THFIND  in  MP)  to  generate  all  possible  candidates  before  any  detailed 
filtering  tests  ore  applied  (a  procedure  which  m0  y waste  an  inordinate 
amount  or  time  in  the  initial  collecting  phase),  in  CONNIVER  it  is 
possiDle  to  call  a "generator"  function  which  will  locate  and  return 
candidates  one  at  a time*  suspending  itself  across  calls.  This  makes 
for  a more  intimate  form  of  interaction  Detween  the  generating  and 
testing  functions  than  is  possible  in  MP,  and  can  lead  to  more 
efficient  searches  because  of  this  intimacy.  To  facilitate  the  use  of 
generators,  CONNIVER  has  some  rather  elaborate  machinery  for 

maintaining  " pos s i oi l i t i e s lists",  including  a function,  TRY-NEXT, 
which  controls  the  extraction  of  possibilities  from  such  lists. 

Computation  in  CONNIVER  is  similar  in  most  other  reoarss  to 
computation  in  MP.  The  counterparts  of  THANTE,  THERA  SING  and  TnCON^E 
theorems  are,  respectively.  I F - ADD  ED  , IF-REMOVED  and  IF-NEtDED 
"methods".  Except  for  differences  in  syntax,  anc  a more  general 
pattern-directed  invocation  scheme,  these  three  functions  are  the  same 
as  the  NP  versions.  CONNIVER  counterparts  of  ip's  database  ar.o 
goal-statement  functions,  THASSERT,  THERASE  and  THGOAL  a re, 
respectively,  ADD,  REMOVE  ana  FETCH, 


3,4.  iliinifiDCX  of  tng  LISP  fiffilii. 

Being  an  interpreted  language,  LISP  is  slower  than,  say,  Fortran, 
by  between  one  and  two  orders  or  magnitude.  However,  cgmEiled  LlaP  un 
be  competitive  with  a good  FORTRAN  compiler.  «e  feel  that  CIbP  provides 
the  Dest  of  both  worlcs,  in  the  sense  that  the  interpreter  provides  fer 
easy  program  development  and  debugging,  while  the  LISP  compiler  can 
transform  debugged  cooe  into  p r od u c t i on -le ve l efficiency. 

MICROPLANNER  ano  CONNIVER,  on  the  other  hand,  are  inherently  leas 
efficient,  primarily  because  ot  the  control  structures  they  superimpose 
on  LISP.  The  fatal  flaw  with  MP  is  its  backup  system,  which  can  te 
extremely  slow;  compilation  will  not  typically  remedy  the  problem. 
fCFJRTtfPR  is  slow  for  similar  reasons;  however,  in  addition  to  data 
structures,  Bt£££££££  must  also  be  garbage  collected,  and  an  elaborate 
context  tree  must  ue  maintained.  Although  these  two  languaoes  contain 
many  noteworthy  features,  we  feel  that  neither  (as  currently 
implemented)  is  appropriate  for  production  applications. 


3.5.  SiindacjiliiifiQ  Si  lh£  LliE  LiQfiUiflfi  Uoii* 

There  are  LISP  systems  for  the  following  machines:  P0P-1C*  PDP-11* 
UNIVAC  11 06 . 1 103  , 11  10,  CDC  6500,  66CD,  IEK  360  , 370,  SIGPA  5,  ar.j 
others.  ceing  a relatively  easy  language  to  implement,  we  wools 
anticipate  no  significant  development  problems  for  any  machine, 
including  microcomputers.  Since  LISP's  syntax  is  nearly  non-existent, 
there  is  exactly  one  aialect.  Although  there  are  minor  differeQces  in 
the  semantics  of  how  functions  are  defined,  and  how  variables  values 
are  accessec,  such  "incompatibilities"  can  normally  be  ameliorated  in 
about  one  day's  worth  of  mac ro-wri ti ng . lecause  of  this,  LISP  can  ^e 
characterizea  as  a language  which  is  fairly  standard  and  t ransport at  It . 
Finally,  most  LISP  systems  have  an  accompanying  compiler,  usu.ll; 
written  in  LISP  itself. 


i 


4 . 


R £ t ed  ntju  a$e  s 


) 

•i 


4.1.  AL 

AL  is  a hign-level  programming  system  for  specification  cf 
manipulatory  tasks,  developed  at  Stanford  Artificial  Intelligence 
Laooratory  LFinkel7«,3.  It  is  a SAIL-like  language  and  incluoes  [arv,e 
runtime  support  for  controlling  devices. 

Trajectory  calculation  is  a crucial  feature  of  manipulator/ 
control.  AL  contains  a wide  range  of  primitives  to  support  efficient 
trajectory  calculations*  As  much  computation  as  possible  is  done  at 
compiie-time  ano  calculations  are  modifiec  at  run-time  only  0s 
necessa  ry  . 

Besides  a o i foe  ns i on l e s s scalar  data  type  (i.e.,  REAL),  AL 
recognises  and  manipulates  TIME.  MASS  and  ANGLE  SCALAPs,  dimensionless 
and  typed  VECTORS,  ROT  (rotation).  FRAME  (coordinate  system),  PLAt.^ 
(region  separator)  ano  TRANS  (transformation)  data  types.  Proper 
composition  of  variables  of  these  types  gives  a simple  means  of 
performing  calculations  of  any  type  of  movement. 

Also  included  are  PL/1-like  ON-eonoit i ons , which  allow  monitoring 
of  the  outside  world,  and  concurrent  processes. 
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a hand  to  move  over  a specifiec 
area.  yellow  is  a hand  ) 
hand  moves  across  plane  ) 
every  3 cm  ) 


i 

i 

i 


do  at  every  iteration  > 


ye  llow  is  also 
hano 


of  hand  j 


1 cm  down  from 
along  Z-axis  > 


current 


coord  system 

yel low  XOR  - Z*CM 

move 

pos it i on 

ON  FORCc(Z)  > 3000  * DYN  ES 

00  TERMINATE;  C keep  in  touch  with  real  world  > 
MOVE  yellow  TO  set  DIRECTLY;  C move  the  hand  back  to  where 

it  was  in  a straight  line  ) 

END  ; 
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4.2.  MWiSE 


MLISP  (meta-LISP)  is  a high-level  l i s t -process  i ng  language 
developed  at  Stanford  University  CSmith7G3.  MLISP  programs  are 
translatec  into  LISP  programs  which  are  then  executed  or  compiled.  The 
MLISP  translator  itself  is  written  in  LISP. 

MLISP  is  an  attempt  to  improve  the  readability  of  LISP  programs  as 
well  as  alleviate  suae  inconveniences  in  the  control  structure  of  LISP 
(e.g.,  no  explicit  iterative  construct).  Since  run-time  errors  arc 
only  detected  by  the  LISP  system  (when  actually  executing  the  program)* 
users  frequently  find  themselves  debugging  the  translated  LISP  codt. 
This  somewhat  defeats  the  purpose  of  any  high-level  language. 

All  LISP  functions  are  recognized  and  translated  in  MLISP*  but  the 
Cambridge  prefix  notation  of  LISP  has  been  replaced  by  standard  infix 
anc  prexix  function  notation.  Instead  of  (PLUS  X Y)  one  may  write  X ♦ 
Y,  ana  (F00  'A  B C)  becomes  F00('A,  9,  C). 

MLISr  also  proviues  a powerful  set  of  iterative  statements  and  a 
large  number  of  “vector  operators."  Vector  operators  are  used  to  apply 
standard  operators  in  a straightforward  manner  to  lists.  Thus*  in 
MLISP,  <1,  2,  3>  *3  <6,  5,  4>  yields  <7,  7,  7> . +3  is  the  vector 
aodition  operator  and  <A*  B*  C>  is  equivalent  to  (LIST  A B C)  in  LISP. 


EiaEBifii 


Given  a list  of  the  form  <obj1,  obj2*  ....  ofcjn>*  this  function 
will  return  a list  of  the  form  <<obj1*  holder1>,  ...*  <otjn,  holdern>> 
where  holderi  is  either  PLIERS*  VISE  or  NOTHING  accordingly  as  needed 
to  hold  the  object,  a ...X  is  an  MLISP  comment. 


EXPR  HOLD-LIST (OBJ -LI  ST) ; i EXPR  starts  a regular  func 

BEGIN 

NEW  S;  X local  declaration 

RETURN  to  RETURN  is  a unary  operator 

FOR  NEW  OF J IN  OoJ-LIST 
COLLECT 

a OBJ  is  local  to  the  FOR  loop. 

X OBJ  will  be  bound  in  turn 
X to  each  element  of  OBJ-LIST. 

X COLLECT  indicates  that  the 
X result  cf  each  iteration  is 
X to  be  APPENDed  to  the  previous 
X result  and  this  whole  list 
X returned  as  the  result  of 
X the  FOR. 

IF  (S  GET (OBJ,  'SIZE))  LEQUAL  5 
THEN 

<<OBJ  * 'PLIERS>> 

EL  SE 

IF  S LESiUAL  10 
THEN 

<<0B J * 'V I SE >> 

ELSE 

«0B J , 'NuTHING>> 


X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 


END; 


f 


4.3.  PQP-2 


POP-c.  is  a conversational  language  desiqneo  by  R.  H.  Eurstall  ano 
R.  J.  Popplestone  at  the  University  of  Edinburgh  [Bur s t a l l 71 j . 

POP-c  features  an  Algol-like  syntax  and  draws  heavily  from  LISF. 
Integers*  reals*  LlSP-like  lists  and  atoms  (callea  'names  )*  function 
constants  (lambda  expressions)*  records*  arrays*  extensible  data  types; 
and  run-time  macros  are  supported*  A unique  feature  of  the  POP-c 
system  is  the  heavy  use  of  a system  stack*  which  the  user  may  easily 
control  to  enhance  the  efficiency  of  programs* 

A full  complement  of  l i st -ma nipu la t ion  * numeric  an. 
s tor ag e -manage men t functions  are  available* 

Examt>i£i 

Suppose  we  wish  to  ODtain  a list  of  all  machinery  not  currently 
functioning*  A useful  function  would  be* 


COMMENT  sublist  returns  a list  of  all  elements  of  argument  list  xl 
which  satisfy  argument  predicate  p ; 

FUNCTION  sublist  xl  p;  < arguments  are  xl  and  p ) 

VARS  x;  { declaration  of  local*  no  type  ) 

IF  null(xl)  THEN  nil  ( just  like  LISP  > 

ELSc  hd(xl)  ->  x;  < no(a)  = (car  a)  > 

IF  p(x  ) 

THEN  x : :subl  i st  ( 1 1 ( x 1)  . p) 

{ tl(a)  - (cdr  a)*  x::l  = (cons  x l)  > 
ELSE  subl i st ( 1 1 ( x l)  , p) 

CLOSE 

CLOSE 

END; 


A call  mibht  then  Loo*  like* 


sublist(machine-list* 

LAMBDA  m;  not (f unct  ioning (m  ) ) END); 


which  right  return* 


Cpunch-pressl  drill-press2  unitlOD 


which  is  a POP-2  list. 


4.4. 

•LISP  is  an  extended  version  of  SA4  (a  pLANNER-like  LISF 
derivative)  CRulifson  19733  embedded  in  the  s oph i s t ic a ted  INTcRLlSP 
system.  GLISP  supports  a wide  variety  of  data  types  designed  to  aic  in 
the  flexiole  handling  of  large  oata  bases.  Among  the  data  types 
supported  are  "TUPLt*"  "BAG"  ano  "CLASS. " A TUPLE  is  essentially  a LISF 
list  that  can  ce  retrieved  a s soci  a t i vely  (see  below).  A BAs>  is  a 
multiset*  an  unoroereo  collection  of  (possibly  duplicated)  elements. 
Bags  have  been  found  to  be  useful  for  describing  certain  commutative 
associative  relations.  A CLASS  is  an  unordered  collection  of 


non-dup  li cated  elements  (i.e.»  basically  a set)* 

Arbitrary  expressions  may  be  storea  in  the  system  data  base  ano 
manipulated  a sso ciat ively . The  QLISP  pattern  matcher  is  used  to 
retrieve  expressions  in  a flexible  manner.  Th$  system  function  MATCHGG 
may  be  used  to  invoke  the  pattern  matcher  explicitly*  as  in: 


(hATCHQQ  (<-X  <-Y)  (A  B>> 


which  causes  X to  be  oound  to  A and  Y to  B indicates  this  "need 
for  a binding**).  The  patterns  to  MATCHGG  may  be  arbitr«rily  complex* 
as  in : 


(MATCHGG  (A  (<-X  <-Y)  ) ( <-X  (A  <B  C)))) 


in  which  X is  bound  to  A and  Y to  (B  C)  . 

QLISP  expressions  are  represented  uniquely  in  the  data  base* 
unlike  LISP  where  only  atoms  are  unique.  To  distinguish  between 
"identical**  expressions*  "properties"  may  be  associated  with  any 
expression  by  QPUT. 


(vPUT  (UNION  (A  B))  EGUIV  (UNION  (B  C))) 


The  above  puts  the  expression  (UNION  (B  C))  uncer  the  property  EQU1V 
tor  the  expression  (UNION  A B). 

QLISP  provides  facilities  for  backtracking  and  pattern-directed 
invocation  of  functions*  as  illustrated  ty  : 


(wLAMBDA  (FRIENDS  JOE  (CLASS  <-F  <-S  <-<-REST)) 
(IS  (FATHER  SS  SF)) 

BACKTRACK) 


This  function  will  find  an  occurrence  of  a CLASS  denoting  FRIENDS  of 
JOE.  F and  S will  be  oound  to  the  first  two  elements  of  the  CLASS  and 
REST  uill  be  bound  to  the  remainder  of  the  CLASS  (indicated  by  "<-<-")• 
If  S is  a father  of  F * then  the  function  succeeds.  ("$"  causes  the 
current  binding  of  its  argument  to  be  used.)  BACKTRACK  causes 
re-invocation  of  the  function  with  new  bindings  for  S*  F and  REST  until 
the  function  succeeos  or  there  are  no  untr ied  'bindings . 

The  user  may  collect  teams  of  functions  to  be  invoked  under 
desired  circumstances.  Many  GLISP  data  base  manipulation  functions  may 
have  optional  arguments  which  denote  a team  of  routines  to  be  used  to 
perform  antecedent-type  functions  (as  in  PLANNER). 

GLISP  provides  a general  context  and  generator  mechanism  similar 
to  that  of  CONNIVER.  Also  provided  is  a smooth*  readily  accessible 
interface  to  the  underlying  INTERLISP  system  which  aids  in  the 
development  and  maintenance  of  large  systems. 

Future  plans  fur  QLISP  include  multiprocessing  primitives* 
semantic  criteria  for  pattern  matching  (as  opposed  to  the  current 
syntactic  information)*  and  the  ability  for  the  pattern  matcher  to 
return  more  information  than  a simple  match  or  fail. 


5.  Examples 


5.1.  lQl£fiS(y£iiSD  • 

A common  example  will  be  useo  to  illustrate  the  d is t 1 ngui sh i n, 
features  of  SAIL.  LISP.  MICROPLANNER  end  CONNIVER.  With  only  miner 
variations  the  program  segments  use  the  same  algorithm.  The 
p rogr a m -s eg  men t s appear  out  of  context  and  are  not  meant  to  indicate 
the  most  ericient  (or  preferred)  implementation  of  the  problem  in  each 
language,  but  merely  to  illustrate  the  languages''  major  attributes. 

Problem  statement: 

Given  two  distinct  assemblies  (say  A1  and  A2),  attempt  to  unscrew  r.1 
from  A2.  and  inoitate  success  or  failure  accordingly.  The  "world"  cf 
the  example  is  assumed  to  include: 

(1)  Two  hands.  LEFT  and  RIGHTj  capable  of  moving.  qraspinb.  twisting 
and  sensing  force  and  motion. 

(2)  A fixed  number  (possibly  zero)  of  PLIERS 
(2)  A fixed  number  (possibly  zero)  of  VISES 
(4)  A fixed  number  of  "assemblies" 


For  each  PLIERS  ana  VISE,  the  data  base  contains  an  assertion  cf 
the  form.  "PLIERS  (VISE)  # n is  at  location  (X,  Y.  Z)  and  is  of 
capacity  t cm."  In  addition,  for  each  assembly  the  data  base  contains 
an  assertion  of  the  form,  “assembly  A is  at  location  (X.  Y,  Z)  ana  is 
of  size  S cm."  As  we  shall  see.  the  language's  are  distinguished  in  part 
by  the  methods  each  uses  to  represent  such  knowledge. 

Each  example  assumes  the  existence  of  the  routines  describee  below 
in  ALGOL** like  notation. 

ATTACHED(A1,  A 2)  - TRUE  if  and  only  if  the  assembly  represented  uy  Al 
(her»after  referred  to  as  Al)  is  attached  to  the  assembly 
representeo  oy  A2  (referred  to  as  A 2).  The  routine  has  no 
side  effects. 


MOVE(HAND,  LOCATION)  - Moves  HAND*  (LEFT  or  RIGHT)  to  LOCATION  (but  see 
PLANNER'S  description  of  MOVE). 


TNI  ST ( HAND*  DIRECTION)  - Twists  HAND  (LEFT  or  RIGHT)  in  the  given 
DIRECTION  (CLOCKWISE  or  COUNTER-CLOCKWISE).  The  DIRECTION  is 
oriented  looking  down  the  length  of  the  arm.  Except  for  SAIL, 
all  programs  assume  a routine  called  TwlST-BOTH.  which  causes 
both  hanas  to  twist  at  once. 


GRASP( HAND,  OBJECT)  - Causes  HAND  (LEFT  or  RIGHT)  to  grasp  OoJECT, 
whici  must  oe  within  some  fixed  range  of  HAND  ( i .e . , the  hand 
must  MOV  c to  the  OBJECT  first). 


ATTEMPT  (ObJ 1 , 06 J c , Al,  A2)  - Attempts  to  do  the  actual  unscrewing  of 
assembly  Al  from  A2  using  objects  UBJ1  ana  06J2  (which,  in  our 
examples,  are  either  VISES  or  PLIERs).  ATTEMPT  returns  TRUE 
if  and  only  if  the  attempt  is  successful. 


Each  program  applies  the  following  sequence  to  solve  the  proolem: 

(1)  Attempt  to  unscrew  the  assemblies  using  the  hands.  This  entails 
ootaining  the  location  of  the  assemblies,  moving  the  hands  to  their 
respective  locations,  grasping,  and  then  twisting. 


(2)  If  the  objects  ere  no  longer  attached*  then  return  "success*" 

(3)  At  this  point*  it  is  assumed  that  the  hands  weren't  strong  enough. 

It  is  proposeo  to  try  two  pairs  of  PLIERS  nest.  A search  ensues 

for  a suitable  set  of  available  PLIERS  (i*e**  large  enough  to  hole 
the  assemblies).  If  one  set  of  PLIERS  fails.  the  search  is 
continued  for  another  set*  with  the  hoce  that  the  differences  aaong 
PLIERS  (grip*  size*  etc.)  will  eventually  lead  to  success* 

(4)  An  attenpt  to  use  PLIERS  has  failed*  Try  to  solve  the  problem  ty 

holding  one  of  the  assemblies  in  a VISE*  Perform  a search  for  an 

appropriate  VISE.  This  search  proceeds  in  a fashion  similar  to  that 

(5)  All  attempts  have  failed*  Output  an  appropriate  message  and  return 
"failure"* 
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5.2.  £AU 
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23 

29 
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31 

32 

33 

34 

35 

36 
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40 

41 

42 

43 
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INTEGER  P KOCE DURE  B 1 G E N OUG  H ( I TE  M VA  k HOLDER,  HOLDEE); 


BEGIN 


••  RETURN  TRUE  IFF  OBJECT  HOLDER  IS  LARGE 
ENOuGH  TO  HOLD  OBJECT  HOLDEE  " 


INTEGER  1TEMVAR  C,  S; 

C COP (CAPACITY  X OR  HOLDER); 
S " COP  (SI ZE  X 0 R HOLDEE ) ; 

R tToRM  DATUM(C)  GEG  DATUMS)) 


END; 


INTEGER  PROCEDURE  UNS  C R E W ( IT  E MV  AR  Al,  A2); 

••  ATTEMPT  TO  DISASSEMBLE  ASSEMBLY  Al  FROM  A2,  0 Y UNSCRcWING 
BtGIN 

DEFINE  kUNME  = 1; 

1TEMVAR  VI,  PL1,  PL  2 , Pi,  P2; 

INTEGER  FLA*; 

IF  NOT  ATTACHED(A1,  A2)  THEN  RETURN(I) ; ” DON'T  BOTHER  " 

MOVE  (LEFT,  LOCATION  XOR  Al  ) ; MOV  E (R  I GHT  , LOCATION  XOR  A «.  ) ; 
GRAS  PILE  FT,  Al);  GRA$P(RIGHT , A2>; 

“ GET  BOTH  HANDS  TWISTING  AT  ONCE  " 

SPROUT ( Pi , TWIST (LEFT,  COUNTERCLOCKWISE),  RUNME); 

S PRO  UT ( P2 , TW  1ST (RIGHT  , COUNTERCLOCKWISE),  RUNME); 

JOIN (<P1  , P 2)  ) ; „ , „ 

IF  NOT  ATTACHEDU1,  A2)  THEN  RETURNd); 

••  HANDS  NOT  STRONG  ENOUGH,  TRY  PLIERS  ” 

FOREACH  PLl,  PL2  | 

ISA  XOR  PLl  EG  V PLIERS  AND  (B  ISENOUGH(  PLl  , AD) 


AND  ISA  XOR  PL 2 EQV  PLIERS  AND  (PLl  NEC  PL 2 ) 
' ' t2 )) 

DO  RETURNd  ); 


AND  (b:genough(pl2,  a; 


AND  (ATTEMPT (PLl,  PL  2 , Al,  A2)) 


" EITHER  THtRE  WEREN'T  ANY  PLIERS  LARGE  ENOUGH, 

OR  THE  PLIERS  WEREN'T  STRONG  ENOUGH.  TRY  A 
VISE  ON  ONE  SIDE  H 

FOREACH  V]§AP^JR*v1  eqv  VISE  AND  (BIGENOUGH  (VI . AD) 
AND  ISA  XOR  PLl  EG  V PLIERS  A!,D  (B I G ENOUGH  ( PLl , 
AND  (ATTEMPT (VI,  PLl,  Al , A2)> 

DO  RETURNd  ); 

" ALL  ATTEMPTS  FAILED  M 


A 2 ) > 


32 


64  OUTSTR<  "CAN'T  UNSCREW  M S C V£S < A 1 , FLAG > * " 

65  & CVIS(A2,  FLAG)  & <15  t '1t>>; 

66  RETdRN(L) 

67 

6b  L WD ; 


- 


_j| 


5.2.2.  Cfiiiscm* 


2.  In  SA.L,  FALSi  = 0,  TRUE  <>  0.  BIG  ENOUGH  is  u BOOLEAN  procedure. 

9.  C and  S are  items  whose  DATUM  is  assumed  to  be  of  INTEGER  type. 

11.  C0P(<set>)  returns  the  first  item  of  <set>.  We  are  assuming  that 
there  exists  only  one  triple  of  the  form  CAPACITY  XOR  <cbject>  EuV 
<capacity>  for  each  <object>. 

13.  C one  S are  necessary  because  DATUM (C0P(<set>))  is  illegal.  s A I L 
must  know  at  compile-time  what  the  type  of  a DATUM  is.  GE*  is  a 
numeric  test  for  greater  than  or  equal. 

23.  UNSCREW  is  a BOOLEAN  procedure  which  returns  TRUE  (non-zero)  if  it 
succeeos  in  unscrewing  the  objects. 

26.  This  is  a macro  definition.  whenever  RUNME  is  encountered  by  the 
SAIL  compiler,  it  will  be  replaced  oy  the  constant  1.  (See  29. 
for  its  use.) 

29.  SPROUT  is  a SAIL  function  which  causes  activation  of  its  seccna 
argument  (a  procedure/function  call)  as  a process.  The  first 
argument  is  an  item  whose  DATUM  will  be  set  by  SPROUT  to  contain 
information  about  the  SPROUTed  process  (see  41.  for  its  use).  The 
thirc  argument  to  SPROUT  oetermines  the  status  of  the  current  and 
the  created  process.  RUNME  (bit  35  set)  indicates  that  the 
current  and  new  processes  are  to  be  run  in  parallel  by  the  SAIl 
s c he  cu ler  . 

47.  BOOLEAN  tests  in  a FOREACH  must  be  enclosed  i r.  parentheses. 

4 £ . Notice  (PLl  NEW  PL 2 ) to  insure  that  two  distinct  pairs  of  pliers 
are  found. 

50.  If  the  body  of  the  FOREACH  is  entered,  then  all  went  well  and  »e 
return  success. 

64.  CVIS  is  a SAIL  function  which  will  return  a character  string 
'name'1  associated  with  an  item.  FLAG  is  set  by  CVIS  to  indicate 
the  presence  of  an  error. 
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5.3.  use 
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5.3.1.  §iiti£  p£fiac§a  \ 


1 

2 

3 

4 

5 
o 

7 

8 
9 

1C 

11 

1^ 

n 

15 

16 

17 
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19 

I? 

22 

23 

24 

25 
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27 
2E 

29 

30 

31 

32 

33 

34 

35 

It 

38 

39 

t? 

42 

43 

44 

45 

46 

47 
46 
49 
5C 

51 

52 

53 
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(GEFUN  UNSCKE*  (A1  A2> 

? ATTEMPT  DISASSEMBLY  OF  OBJECT  A1  FROM  A2,  BY  UNSCREWING 
(PROG  (PL  1 PL 2 VI  IN) 

(COND  C (NOT  (ATTACHED  A1  A2>)  (RETURN  T)3) 

(MOVE  'LEFT  (GET  A1  'LOCATION)) 

(MOVE  'RIGHT  ( 6ET  A2  LOCATION)) 

(GRASP  'LEFT  A 1 ) (GRASP  'RI6HT  Ac) 

(TW 1 ST-EOTH  'COUNTER-CLOCKWISE) 

(COND  £ (NOT  (ATTACHED  A1  A2) ) (RETURN  T)3) 

? HANDS  NOT  STRONG  ENOUGH,  TRY  PLIERS 

(COND  C ( FORE ACH  PLl  IN  PLIERS-LIST  (BIGENOUGH  PL1  Al) 

PL2  IN  PLIERS-LIST  (AND  (NOT  (EG  PLl  PL2)) 

(BIGENOUGH  PL2  A2)) 

DO  (ATTEMPT  PLl  PL2  Al  A2)) 

(RETURN  T)3 

? PLIERS  NOT  LARGE  ENOUGH  OR  NOT  STRONG  ENOUGH. 

? TRY  A VISE  ON  1 SIDE 

C ( F ORE  ACH  VI  IN  VISE-LIST  (BIGENOUGH  VI  AD 

PLl  IN  PLIERS-LIST  (BIGENOUGH  PLl  A2 ) 

DO  (ATTEMPT  Vi  PLl  Al  A2)) 

(RETURN  T ) 3 

? ALL  ATTEMPTS  FAILED 

CT  (PRIN1  "CAN'T  UNSCREW  ")  (PRIN1  Al ) 

(PR  INI  " 8 ")  (PRIN1  A2)  (TERPRI) 

(RETURN  NIL)3> 


(DEFUN  BIGENOUGH  (HOLDER  HOLDEE) 

? RETURN  T IFF  OBJECT  HOLDER  IS  LARGE  ENOUGH  TO 

? hold  object  holdee 

(NOT  (LESSP  (GET  HOLDER  'CAPACITY) 

(GET  HOLDEE  'SIZE))) 


) 


(DEFSPEC  FOREACH  (LAMBDA  (OBJ1  INI  LIST1  PRED1 

OB J 2 IN2  LIST2  PRE  D 2 
DO  TRY) 

? MIMIC  SAIL  FOREACH  IN  SIMPLE  CASE 
(PROG  (TEMPI  TEMP2) 
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1 


4 
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63 

64 

65 

66 
67 
66 

69 

70 

71 

72 

73 

74 

75 
7 o 
77 

76 
79 
SO 
31 
30 


64 

85 

36 

37 
£3 

89 

90 

91 
90 
93 
v4 

95 

96 

97 

II 

100 

101 

102 

103 


LO0P1 


LOOP2 


) )) 


(SETQ  TEMPI  (EVAL  LlSTl)) 

(COND  t (NULL  TEMPI)  (RETURN  ML)3)  ? PAN  OUT 

(SET  OB  J 1 (CAR  TEMPI  )) 

(SETQ  TEMPI  (CDR  TEMPI)) 

(CONO  C (NOT  (EVAL  PRED1))  (GC  LOOPDO)  ? FAILED  1ST  TEST 
(SETO  TEMP2  (EVAL  L I ST2 ) ) 

(COND  L (NULL  TEMP2)  (GO  L OOP  1)0) 

(SET  OBJ2  (CAR  TEMP2  )) 

(SETQ  TEMP2  (CDR  TEMP2) ) 

(COND  [(NOT  (EVAL  PRED2))  (GC  LOOP2)] 

[ (EVAL  TRY)  (RETURN  T)3  ? IT  WORKED 

CT  (GO  LOOP2 ) 3 ) 


(DEFMAC  FoRtACH  (LAMBDA  (oBJl  INI  LIST1  PRED1 

OBJ2  IN2  LISTS  PRED2 
DO  TRY) 

? MACRO  VERSION  OF  FORcACH 

(LIST  'PROG  '(LI  L 2 ) 

(LIST  'SETQ  'LI  LIST1) 

' LOOP1 

'(COND  [(NULL  Li)  (RETURN  ML)]) 

(LIST  'SETQ  OB J 1 '(CAR  Li)) 

'(SETQ  ^1  (CDR  Li)) 


'loo pi 


) ) 


(LIST  'COND 
(LIST  'SETQ 


ST  (LIST  'NOT  PRED1) 
LIST  2) 


(COND  C (N  ULL  L 2 ) (GC  LOOPDO) 

(LIST  'SETQ  OB J 2 '(CAR  L2  ) ) 

(SETQ  Lc  (CDR  L2)) 

(LIST  'COND  (LIST  (LIST  'NOT  PRED2) 
(LIST  TRY  '(RETURN  T)) 
'(T  (GO  LOOP2))) ) 


'(GC  LOO  PI  ) ) ) 


'(GO  LOO»2)) 


5.3.2.  £wfflB£D lit l 


UNSCRtW  is  the  main  function.  It  returns  T if  and  only  if 
uisassemDly  .as  successful. 

Unlike  SAIL*  LISP  does  not  support  concurrency.  We  thus  assume  a 
primitive  function  to  get  both  hands  twisting. 

FOREACH  is  an  iterative  special  form  which  mimics  a simple  SAIL 
FOREACH.  FGRcACH  will  try  pairs  of  pliers  until  the  given 
predicates  succeed  or  it  runs  out  of  pliers  (and  returns  NIL). 
Note  that  the  arguments  to  a special  form  need  not  be  quoted. 

Check,  to  insure  that  distinct  pairs  of  pliers  are  found. 

PRINl  is  a LISP  function  which  loads  its  argument  into  the  stream 
output  buffer. 

TERPR1  is  a LISP  function  which  dumps  the  output  buffer. 

Return  T if  capacity  >=  size. 

DEFSPEC  defines  a special  form  (sometimes  called  a FEXPR).  A 
special  form  is  identical  to  a LISP  function  except  that  its 
arguments  are  passed  unevaluated. 

EVAL  is  necessary  since  the  argument  was  passed  unevaluated. 

Note  the  use  of  SET  rather  than  SETQ.  OdJI  needs  to  be  evaluated 
to  v*t  the  intenoed  atom  (SET  evaluates  its  first  argument*  SETQ 
does  not)  • 

Note  the  use  of  EVAL  (see  63.). 

Note  the  use  of  s e. T (see  66.). 

This  is  an  alternative  macro  version  of  FOREACH.  It  expands  into 
a PR06  which  is  similar  in  nature  to  the  special  form  FOk  E A Ch  • 
Note  the  absence  of  SET  or  EVAL* 
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5.4.1.  EC fia£2 Q! 


(THCONSE  UNSCREW  (A1  A?) 

(UNSCREW  (THV  Al)  (THV  AS)) 


ATTEMPT  DISASSEMBLY  OF  OBJECT  Al  FROM  AS,  EY  UNSCREWING 


( THOR 


(THNOT  (ATTACHED  (THV  Al)  (THV  At)) ) 

( THA  HD 

(THGOAL  (MOVE  LEFT  (THV  AD)  ( T HT c F THTRUE)) 

(THGOAL  (MOVE  RIGHT  (THV  AS))  (THTBF  THTRUE)) 

(GRASP  'LEFT  (THV  AD)  (GRASP  'RIGHT  (THV  AS)) 
(TwIST-BOTH  'COUNTER-CLOCKWISE) 

(THNOT  (ATTACHED  (THV  Al)  (THV  AS))) 

) 

H AND  5 NOT  STRONG  ENOUGH,  TRY  PLIERS 
(THPROG  (PLl  PLS) 

(THGOAL  (ISA  (THV  PLl)  PLIERS)  (THTBF  THTRUE)) 

(THGOAL  (BIGENOUGH  (THV  PLl)  (THV  AD)  (THNODB) 

(THUSE  BIGENOUGH)  (THTBF  THTRUt)) 
(THGCAL  (ISA  (THV  PL *)  PLIERS)  (THTBF  THTRUE)) 

(THNOT  (EC  (THV  PLl)  (THV  PLS))) 

(THGOAL  (BIGENOUGH  (THV  PLS)  (THV  A2))  (THNODB) 

(THUSE  EIGENOUGH)  (THTbF  THTRUE)) 
(ATTEMPT  (THV  PLD  (THV  PL2 ) (THV  Al)  (THV  A2)) 

) 

no  pliers  large  enough,  or  no  pliers  strong  enough. 

TRY  K VISE  ON  1 SIDE 
(THPROG  (VI  PL) 

(ThGOAl  (ISA  (THV  Vi ) VISE)  (THTBF  THTRUE)) 

(THGOAL  (BIGENOUGH  (THV  Vi)  (THV  AD)  (THNCDB) 

(THUSE  BIGENOUGH)  (ThTBF  ThTRUE)) 
(THGOAL  (ISA  (THV  PL)  PLIERS)  (THTBF  THTRUE)) 

(THGOAL  (EIGENOUGH  (THV  PL)  (THV  A2D  (THNCDB) 

(THUSE  EIGENOUGH)  (THTEF  ThTRUE)) 
(ATTEMPT  (THV  VI)  (THV  PL)  (THV  A1)  (THV  AS)) 

) 

NOTHING  wORKEC  , JUST  FAIL 
(THNOT  ( TH  DO 

(PPiNl  "CAN'T  UNSCREW  ")  (PRIN1  (THV  AD) 

( P c IN  1 " ">  (PRIN1  (THV  AS))  (TERPRI) 

) ) 

(THFAIL  THEOREM) 


(THCONSE  dIuENOUGH  (HOLDER  HOLDEE  C S) 

(BI6ENOUGH  (THV  HOLDER)  (THV  HOLDEE)) 

? SUCCtEuS  ONLY  IF  OBJtCT  HOLDER  IS  LARGE  ENOUGH  TO  HOLD 
? OBJE  CT  HOLDEE 

(THGOAL  (CAPACITY  (THV  HOLDER)  (THV  C))  (THTBF  THTRUE ) ) 
(THGOAL  ( SIZE  (THV  HOLDEE)  (THV  S)>  (THTBF  THTRUE)) 


5.4.2.  CfigsfiQiirx 


2.  Defines  end  asserts  a consequent  theorem  with  name  UNSCREW. 

3.  This  is  the  pattern  on  which  to  invoke  this  theorem  if  neeoeo 

( e .g  . , (UNSC  REw  AS  SENBLY 1 ASSEMBLY2  ))  . 

7.  THOR  sequentially  executes  each  of  its  arguments  until  one 

succeeds.  and  then  the  THOR  succeeds.  The  THOP  is  used  here  to 
prevent  undesireo  oackup. 

8.  (THNOT  p)  is  aefinea  as  (COND  [p  (THFAID3  CT  (T  H SUCC  E ED ) 3 ) . 

9.  THAND  succeeds  if  and  only  if  all  of  its  arguments  succeeo.  unlike 

THOR,  backup  may  occur  among  the  arguments  of  a THAND. 

13.  Attempt  to  move  the  left  hana  to  object  Al.  There  may  be  several 
experts  (theorems)  on  moving  hands.  PLANNER  will  try  as  many  as  it 
needs.  (TH T8 F ThTRUE)  is  a theorem  base  "filter"  which  is 

satisfied  by  every  theorem. 

19.  THFRO&  behaves  in  a similar  manner  to  THAND  except  that  local 

variables  may  be  declared. 

2 3.  Attempt  to  fina  a pair  of  pliers. 

21.  See  if  the  pair  of  pliers  is  large  enough.  (THNODB)  indicates  to 

PLANNER  not  to  pother  searching  the  data  base.  (THUSt  <theoreir>) 
inoicates  to  try  <theorem>  first. 

24.  Hake  sure  that  we  have  two  distinct  pairs  of  pliers. 

45.  T H DO  executes  its  arguments  and  then  succeeds.  However,  at  this 
point  we  know  that  we  have  faileo,  and  THNOT  is  used  to  generate  a 
failure  from  T HD 0 • This  is  necessary  because  PRINl  returns  its 

first  argument  as  its  result,  which  (being  non-NlL)  would  cause 
the  THOR  to  succeeo. 

49.  Generate  explicit  failure  of  the  theorem. 
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(cdefjn  unscrew  (ai  a2> 

? ATTEMPT  TO  DISASSEMBLE  Ai  FROM  AZ,  BT  UNSCREfc  !NG 

"AUX"  (LOCI  LOC2  GENl  6E,\Z  VI  PLl  F L 2 ) 

( C 0 rt  D [(NOT  (ATTACHED  AI  A2)  ) (RETURN  T ) 3 ) 

(PRESENT  '(LOCATION  !,A1  !>LOCl)> 

(PRESlNT  '(LOCATION  !,A2  !>l0C2)) 

(MOVE  'LEFT  LOCI)  (MOVE  'RIGHT  LCC2) 

(GRASP  'LEFT  AD  (GRASP  'RIGHT  A2> 

(COND  KNOT  (ATTACHED  AI  A2>>  (RETURN  T>3> 

? HANDS  NOT  STRONG  ENOUGH,  TAT  FlIERS 

(CScTl  GENl  ‘"((-POSSIBILITIES)  *IGNG«F 

(•GENERATOR  (NEXT-OLJ  'PLIERS  '(GIGE  R'CUGH  S »1))))) 

: PLOOP  1 

( C S cT.  PLl  (TRY-NEXT  GENl  '(GO  'TRY-VISE))) 

(CStTw  oE  N2  ‘"((-POSSIBILITIES)  -IGNORE 

(•GENERATOR  (NEXT -OBJ  'FLIERS 

'(AND  (NOT  (EG  PLl  *)) 

(BIG  ENOUGH  S AZ)))))) 

: FLOOP2 

( CS  cTl  PL  2 (TRY-NEXT  GEN?  '(GG  'PLOOP1))) 

(CONC  [(ATTEMPT  PLl  PL2  Ai  A2)  (RETURN  T)j 
[T  (GU  PLOOP2  )3) 

? NO  PLIERS  LARGE  ENOUGH,  OR  «>LI£RS  NOT  STRONG 
? ENOUGH.  TRY  A VISE  GN  ONE  SIDE. 

• TRY -VISE 

(CStTv.  lE  M !"((*POSSIBILITIES)  -IGNORE 

(•GENERATOR  (NEXT-OLJ  'VISE  '(PIGENOUG"  1 AI))))) 

: VL  OOP 

(CS£Tl  VI  (TRY-NEXT  CENl  '(GC  'NC-C AN-D 0 ) ) ) 

( C S lT*  uE  N2  ! "( ( ‘P0SSI9ILITI ES)  -IGNORE 

(•GENERATOR  (NEXT-CBJ  PLIERS  '(PIGENOUGH  S A..))))) 

: PL  OOP  3 

(CScTu  PLl  (TRY-NtXT  GEN?  '(GC  'VLOCP))) 

(COND  [(ATTEMPT  VI  PLl  Ai  AZ  ) (RETURN  T)3 
[T  (GO  'PLOGP3)3) 

? ALL  ATTEMPTS  FAIlED 

: NO-CAN-D  u 

(PR  INI  "CAN'T  UNSCRtW  ")  (PRIM  AI) 

(PRINI  " ")  (PRIM  A2)  (TERPRI) 

(RETURN  NIL) 

) 


( CDEFJN  B iGENOUGH  (HOLDER  HOLDEE) 

? RETURN  T IFF  OBJECT  HOLDER  IS  LARGE 
? ENOUGH  TO  HOLD  OBJECT  HOLDEE 

"AUX"  (C  S) 
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5.5.2.  £ct®£Qtary 

2.  COE  FUN  defines  a function  to  CONNIVER. 

6.  " A U X"  <List>  oefines  local  variables* 

13.  PRESENT  is  a CONNIVER  function  which  searches  the  data  base  for  «n 
item  which  matches  its  pattern  argument.  If  one  is  founo,  PRESENT 
sets  the  indicated  variables  (marked  with  !<  or  !>  ) .no  returns 
the  item.  !,A1  indicates  the  current  CONNIVER  value  cf  A1. 
!>L0C1  indicates  that  LOCI  is  to  be  bound  if  possible. 

IE.  oENl  is  oein*  assigned  a TRY-NeXT  possibilities  list.  !"  tells 
CONNIVER  to  do  a "skeleton  expansion"  of  the  following  list  (which 
is  necessary  to  CONNIVER"s  internals).  The  (‘POSSIBILITIES)  a no 
•IGNORE  are  syntatic  markers  to  TRY-NEXT  whose  function  we  can 
iqnore.  (•uENERATOR  <fune-call>)  indicates  to  TRY-NEXT  to  use 
<func-call>  to  generate  additional  possibilities  if  needed. 

1?.  NEXT -OBJ  will  continue  to  generate  objects  of  type  PLIERS  which 
satisfy  the  predicate  (2nd  argument).  It  will  generate  one  PLIERS 
at  a time.  (6IGEN0UGH  S A1)  is  a skeleton  predicate  which 
NEXT -OBJ  will  use  to  screen  each  possibility.  The  current 
candidate  is  substituted  for  S before  the  predicate  is  CVALuatta 
( CONNIVER  " s form  of  EVALuation). 

21.  when  GEN1  contains  no  more  possibilities?  TRY-NEXT  will  execute 
(GO  "TRY-VISE).  Unlike  LISP,  GO  evaluates  its  argument  here. 

24.  Check  to  insure  that  two  distinct  pair.,  of  pliers  will  be  founc. 

6w.  See  13. 

66.  RETURN  is  not  necessary  since  the  value  of  a CONNIVER  function  is 
the  last  expression  evaluate^. 

. Define  the  generator,  NEXT-OtJ.  Note  that  NEXT-G?J  looks  like  a 
regular  function  to  CONNIVER  until  it  is  called. 

79.  FETCH  is  a CONMVER  primitive  which  returns  a possibilities  list 
of  all  items  in  the  data  base  which  match  its  pattern  argument. 
! > OB J indicates  that  OBJ  should  be  bound  by  TRY-NEXT  to  each 
possibility  in  turn. 

51.  TRY-NEXT  binos  OdJ  from  the  possibilities  list  TEMP  and  removes 
the  current  possibility.  If  there  is  no  current  possibility? 
(ADIEU)  is  evaluated  which  causes  termination  of  the  generator. 

22.  The  oesired  predicate  is  CVALuated  after  substituting  the  current 
object  into  the  skeleton.  (SUBST  A B C)  is  a LISP  function  which 
returns  a list  which  is  the  result  of  substituting  A for  every 
occurrence  of  fc  in  list  C. 

22.  (NOTE  OdJ)  is  a CONNIVER  function  which  places  the  current  value 
of  OoJ  otto  the  current  possibilities  list.  . 

54.  (AU-REVOIR)  returns  control  from  NEXT-OBJ  out  leaves  the  generator 
in  a suspended  state.  when  TRY-NEXT  returns  control  to  NEXT-OBJ, 
execution  will  resume  at  (GO  "LOOP). 


6*  £2Q£lfcii2GS 

Either  SAIL  or  LISP  could  provide  an  excellent  basis  for  real-time 
planning  and  execution  control  of  a large  automated  shop.  However,  each 
language  possesses  features  which  facilitate  certain  types  cf 
operations.  In  particular,  SAIL  is  generically  better  at  the  low  level 
control  of  I/O  devices,  and  has  more  extensive  abilities  for 
interacting  with  the  operating  system  (especially  where  file 
manipulations  are  concerned).  LISP,  on  the  other  hand,  is  more  flexible 
at  the  higher  planning  levels  and  where  system  development  and 
debugging  are  concerned. 

wie  envision  an  "ideal"  system  as  one  which  merges  all  the 
desirable  features  of  these  two  language  classes.  Such  a merger  woulc 
incorporate  LISP's  program  and  data  structure  format,  augmented  where 
necessary  to  accommodate  SAIL-liwe  file  operations,  and  possibly  LEAP. 
SAIL  features  would  be  implanted  in  this  environment,  and,  at  tr.e 
implementor  s discretion,  an  ALGOL-like  syntax  (such  as  MLISP)  coulo  te 
grafted  onto  the  front  of  the  system  to  make  it  more  tractable. 

In  audition,  such  a merger  should  take  care  to  preserve  tne 
following  desirable  features  of  SAIL  anc  LISP: 

(1)  vata  structures  should  accommodate  complex  symbolic 
information  as  well. as  primitive  types.  As  in  LISP,  data 
structures  should  be  free  to  grow  in  unrestricted  ways,  and 
storage  declarations  should  be  optional  to  the  user. 

(i)  Program  and  data  should,  as  in  LISP,  be  in  the  same  format. 

Such  a representation  underlies  (a)  a strong  macro 
facility,  (b ) rapid  editing,  modification  ano  debugging  of 
programs,  anu  (c)  se If -modi f yi ng  and  se  If -ex t endi ng 
systems.  The  last  capauility,  for  example,  enables  the 
system,  given  the  description  of  a new  type  of  tool, 
automatically  to  synthesize  the  programs  for  controlling 
the  tool  from  a library  of  sub- f un c t i ons . 


(3)  Strong  I/O  ana  file  manipulation  facilities,  as  are  found 
in  SAIL,  must  be  included.  A good  random-access  file  system 
is  imperative  for  even  moderately  large  databases.  The 
system  should  have  both  high  and  low  level  control  over 
input  and  output  formatting  which  provides  control  down  to 
the  bit  level  of  the  machine. 

(A)  A highly-developed  interrupt  subsystem  would  be  desirable. 
With  the  merger  of  SAlL's  bit-wise  interrupt  control,  and 
LISP  s symbolic  capabilities,  such  a system  as  is  described 
in  CRieger  763  could  be  efficiently  implemented.  This  would 
serve  as  the  network  protocol  for  a large  collection  of 
highly  autonomous  processes  where  the  synthesis  and  control 
of  many  parallel  events  is  important* 

(5)  For  software  development  and  debugging,  an  interpreter 
should  exist  for  the  language.  Nevertheless,  the  language 
should  be  have  a compiler  for  production  usage.  LISP 
currently  satisfies  these  requirements. 

(6)  The  system  should  provide  for  a large,  context-sensitive, 

associative  database.  This  would  involve  some  new 

engineering  to  coordinate  a MP-like  database  with  an 
efficient  random-access  file  system.  CmcDermott75a3  surveys 
some  ideas  on  this  topic. 

(7)  There  shoulo  oe  some  degree  of  automatic  problem-solving 
control  which  includes  a CONNIVER-like  cont ext -sw i t c hing 
and  process-suspending  mechanism.  Accommodations  should  be 
made  for  SAIL-like  parallel  process  control,  and  emphasis 
should  oe  placed  on  inter-process  communications  protocols. 
Most  of  the  ideas  already  exist  in  CONNIVER  and  SAIL,  but 
they  need  to  be  synthesized  into  a unified  system. 
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